Support from Acquia helps fund testing for Drupal Acquia logo

Comments

longwave’s picture

The same function also sets an HTML ID which doesn't appear to be referenced from CSS or JS:

    $variables['attributes']['id'] = 'authorize-results';

If this can be safely removed, then perhaps the wrapper div can also be safely removed, and then we appear to be left with just an item_list - meaning it may be possible to remove this template entirely?

joelpittet’s picture

Title: Strong tag should be moved to CSS in template_preprocess_authorize_report function. » Replace strong tag with CSS in template_preprocess_authorize_report and remove id..
Issue tags: -Twig conversion +Novice, +CSS

I agree, title changed and lets do that here. The class name may need to be BEMized. @see component in https://drupal.org/node/1887918

Maybe move authorize-results to a class and rename .failure to .authorize-results__failure?

mrjmd’s picture

Assigned: Unassigned » mrjmd
Status: Needs review » Active

Going to try my hand at this one.

mrjmd’s picture

Assigned: mrjmd » Unassigned
Status: Active » Needs review
FileSize
1.39 KB

My attempt at a patch.

Status: Needs review » Needs work

The last submitted patch, 4: core-replace-strong-tag-with-css-2215543-4.patch, failed testing.

mrjmd’s picture

My patch was made against the patch in https://drupal.org/node/1885564#comment-8733979, which hasn't been committed yet. I think that's why it has failed testing.

vollepeer’s picture

Assigned: Unassigned » vollepeer
vollepeer’s picture

Status: Needs work » Postponed
vollepeer’s picture

Assigned: vollepeer » Unassigned
Antti J. Salminen’s picture

joelpittet’s picture

Status: Postponed » Needs work

This patch should be possible on it's own. That other issue is a conversion from theme_ function to twig template so other than maybe a merge conflict this should be still good to go. Conversion issues should be straight conversions as much as possible, no new features added.

#4 Looks fairly good. Just make the patch against 8.x branch.

+++ b/core/modules/system/css/system.maintenance.css
@@ -43,3 +43,10 @@
+.authorize-results__failure {

the class is called .failure and it would be inside .authorize-results and not bemized yet. Though you could "bemize" them I think that is scope for a different issue.

Sorry for the late response @mrjmd, but thanks for the patch nevertheless.

mrjmd’s picture

Assigned: Unassigned » mrjmd

joelpittet, thanks for the feedback. i'll roll a new patch against HEAD.

mrjmd’s picture

mrjmd’s picture

Assigned: mrjmd » Unassigned
Status: Needs work » Needs review
joelpittet’s picture

@mrjmd thanks for the new patch, here's a review:

  1. +++ b/core/includes/theme.maintenance.inc
    @@ -155,7 +155,7 @@ function theme_authorize_report($variables) {
    -    $output .= '<div id="authorize-results">';
    +    $variables['attributes']['class'] = 'authorize-results';
    
    @@ -176,7 +176,6 @@ function theme_authorize_report($variables) {
    -    $output .= '</div>';
    

    This is the only change that may be a bit premature though I like the idea very much. The problem is you added a class that that never gets used(may get used in the twig template... I don't know). Two options here, just remove the div all together, or the more pragmatic approach just change the id to class in the string. I'd favour the latter.

  2. +++ b/core/modules/system/css/system.maintenance.css
    @@ -43,3 +43,10 @@
    + * Theme maintenance styles
    ...
    +.failure {
    +  font-weight: bold;
    

    This should be prefixed with .authorize-results class just like:
    .update-results .failure further up the page.
    Or for bonus points do the bem naming like you did earlier and not worry about naming collisions. I'm not sure when/where those bem naming are to go in or which issues they are from but worth a shot. But to be on the safe side you could just copy the pattern before you.

  3. +++ b/core/modules/system/css/system.maintenance.css
    @@ -43,3 +43,10 @@
    +}
    \ No newline at end of file
    

    This needs a newline.

LewisNyman’s picture

Status: Needs review » Needs work
Issue tags: +frontend
alexrayu’s picture

Assigned: Unassigned » alexrayu
FileSize
1.33 KB
1.14 KB

Please check it out.

alexrayu’s picture

Status: Needs work » Needs review
LewisNyman’s picture

Assigned: alexrayu » Unassigned
Status: Needs review » Needs work

This still needs work to be brought in line with our CSS standards, apart from that it looks good.

Or for bonus points do the bem naming like you did earlier and not worry about naming collisions. I'm not sure when/where those bem naming are to go in or which issues they are from but worth a shot. But to be on the safe side you could just copy the pattern before you.

olemedia’s picture

Assigned: Unassigned » olemedia
olemedia’s picture

Assigned: olemedia » Unassigned
Status: Needs work » Needs review
FileSize
1.35 KB

Renamed the classes to conform with Drupal naming convention: See https://drupal.org/node/1886770

joelpittet’s picture

+++ b/core/includes/theme.maintenance.inc
@@ -198,7 +198,7 @@ function theme_authorize_message($variables) {
     $item = array('data' => $message, 'class' => array('success'));

Should we do success here too? to make them consistent in naming pattern? Otherwise this is RTBC from me.

Antti J. Salminen’s picture

Assigned: Unassigned » Antti J. Salminen
Antti J. Salminen’s picture

Changed the success classname to be consistent with failure. Also added type hinting to function signature/docblock for the functions this patch touches. Hopefully that change is not out of scope.

star-szr’s picture

It looks out of scope to me, try and keep the changes focussed, it makes patches easier to maintain (reroll) and review/commit. Thanks!

Antti J. Salminen’s picture

Got it, here's the patch with only the consistent class naming modification.

joelpittet’s picture

Awesome, this looks great to me. I double checked and there are no css or js in core using the ID or class for these theme so we should be good there.

Not exactly sure how to get to the page to see this though for manual testing...
One part of the puzzle is turning on allow_authorize_operations = TRUE in settings.php from the authorize.php docblock.

Antti J. Salminen’s picture

allow_authorize_operations appears to be TRUE by default so you don't have to change that. I tried to test by installing a module through the UI but seems like the process is broken. #842620: Update manager can't install modules using FTP due broken FileTransferAuthorizeForm is a related but old issue which doesn't contain the exact error I'm getting now... Looks to be difficult that way currently.

LewisNyman’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs manual testing, -Needs steps to reproduce, -Novice +Amsterdam2014

This patch looks done? RTBC!

alexpott’s picture

How does this go with the effort to move classes into template files? Or have we decided to not move the authorise theme functions into templates?

star-szr’s picture

We are still converting authorize.php to Twig, when it's Twig then we can move at least some of this to the template.

#1885564: theme.maintenance.inc (authorize.php) - Convert theme_ functions to Twig

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 69c5468 and pushed to 8.0.x. Thanks!

  • alexpott committed 69c5468 on 8.0.x
    Issue #2215543 by Antti J. Salminen, mrjmd, alexrayu, olemedia |...
joelpittet’s picture

Thank you @alexpott :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.