Support from Acquia helps fund testing for Drupal Acquia logo

Comments

NROTC_Webmaster’s picture

Status: Active » Needs review
FileSize
15.51 KB

First attempt. The themes seem to be horribly documented and I'm a little uncertain even how some of the files should be handled. I tried to give fairly generic descriptions because I don't really use the themes.

jhodgdon’s picture

Status: Needs review » Needs work

Hmmm... This looks like a good start. I reviewed the Bartik changes, and have these comments:

a) I am not sure what those .html files do, but I don't think we should add PHP tags to them, so I think we should not have @file in there. Eek! Too scary to contemplate. :)

b) I would also not change this line in color/preview.js:

-(function ($) {
+ (function ($) {

c) For the template.php file, I think a better @file description would be:

Functions to support theming in the Bartik theme.

d)

+++ b/core/themes/bartik/templates/comment-wrapper.tpl.php
@@ -3,7 +3,9 @@
 /**
  * @file
  * Bartik's theme implementation to provide an HTML container for comments.
- *
+ */
+
+/**
  * Available variables:
...

Actually that should all be in the @file. See
http://drupal.org/node/1354#templates

e) The same goes for the other .tpl.php files. They all need to be modified to fit that standard.

NROTC_Webmaster’s picture

Status: Needs work » Needs review
FileSize
12.87 KB
15.77 KB

Thanks for the quick response. The stark template.php says

* @todo Based on outcome of http://drupal.org/node/1471382, revise this
* technique to use conditional classes vs. conditional stylesheets.

Since that issue is closed (won't fix) should I remove it from the docblock?

Other than that I have updated the patch to comply with the documentation.

jhodgdon’s picture

FYI - When putting links to issues on drupal.org, use the [#...] syntax, where ... is the issue's node ID. Makes nicer links. :)

Regarding that @todo - that is beyond the scope of this issue, and that other issue has several comments indicating there might be a follow-up, so I would just leave it alone.

Anyway... thanks, and someone (probably xjm or I) will try to review this sometime soon. :)

tim.plunkett’s picture

tim.plunkett’s picture

FileSize
15.79 KB

derp.

filijonka’s picture

Status: Needs review » Needs work

in the template.php (all themes)

all functions named hook_preprocess_hook or hook_process_hook should be documented as hooks, see [#1354-hookimpl]

jhodgdon’s picture

RE #7 - that is true if the hooks are listed at http://api.drupal.org/api/drupal/core!includes!theme.inc/function/theme/8

For instance, a function called bartik_preprocess_html should be documented as:

Implements hook_preprocess_HOOK() for html.tpl.php.

(thereby telling us which HOOK it is for).

NROTC_Webmaster’s picture

Just to be sure, the following functions should have that type of documentation?

Most of these currently say "Overrides or inserts ..." but should instead say what they are implementing.

drupal\core\themes\bartik\template.php
Line 33: function bartik_process_html(&$variables) {
Line 43: function bartik_process_page(&$variables) {
Line 94: function bartik_process_maintenance_page(&$variables) {

drupal\core\themes\bartik\template.php
Line 11: function bartik_preprocess_html(&$variables) {
Line 112: function bartik_preprocess_block(&$variables) {

drupal\core\themes\seven\template.php
Line 11: function seven_preprocess_maintenance_page(&$vars) {
Line 23: function seven_preprocess_html(&$vars) {
Line 31: function seven_preprocess_page(&$vars) {

drupal\core\themes\stark\template.php
Line 14: function stark_preprocess_html(&$variables) {

tim.plunkett’s picture

The existing lines could be left in, but they are often redundant.

If left in, it should look like this:

/**
 * Implements hook_process_HOOK() for html.tpl.php.
 *
 * Override or insert variables into the page template for HTML output.
 */
function bartik_process_html(&$variables) {
jhodgdon’s picture

I would take out a line like the second one in #10. As stated there, it's redundant.

NROTC_Webmaster’s picture

Status: Needs work » Needs review
FileSize
5.11 KB
16.12 KB

The latest is attached with the diff from #6.

jhodgdon’s picture

Version: 8.x-dev » 7.x-dev
Status: Needs review » Patch (to be ported)

This patch looks good, and I think it's safe to commit even though we're over thresholds (doesn't seem to conflict with any of the critical/major issue patches in the queue). So, I committed it to 8.x! Thanks!

Next up: port to D7.

NROTC_Webmaster’s picture

This one seems fairly straightforward but since the theme standard was added for D8 I will refer to your best judgement.

NROTC_Webmaster’s picture

Status: Patch (to be ported) » Needs review

This one seems fairly straightforward but since the theme standard was added for D8 I will refer to your best judgement.

jhodgdon’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs review » Needs work

This looks pretty good -- I think it is fine to use the hook_preprocess_HOOK() doc standard in D7, because the alternative is linking to functions that do not exist (i.e., won't make links).

I did notice this:

+++ b/themes/bartik/templates/comment-wrapper.tpl.php
@@ -33,6 +33,8 @@
  *
  * @see template_preprocess_comment_wrapper()
  * @see theme_comment_wrapper()
+ *
+ * @ingroup themeable

Did we do that in d8? We should not have. The @ingroup themeable should only be on the base theme implementation, not in overrides of it in individual themes.

... Yes, it looks like we did that in the D8 patch. Let's go back and fix that. All of those @ingroup themeable lines need to be taken out of all the themes' tpl.php files.

Other than that, the D7 patch looks good.

jhodgdon’s picture

And I just clarified that on http://drupal.org/node/1354#templates

jhodgdon’s picture

Issue summary: View changes
Status: Needs work » Closed (won't fix)

These issues are a lot of work with very little tangible payoff, so I'm closing the rest of them as "won't fix". Your efforts on working on this issue were appreciated... it was just my fault for starting a task that was very difficult to get right.

Let's instead put our effort into fixing and reviewing documentation that is really unclear and/or wrong, and I hope that the people who worked on these issues are not afraid to jump into a more reasonable issue!