Styling the Backend!

[Don Chambers]

Yes - I know for a fact that admin styles specifically address the <li>. I just don't like that, although they have the additional class of serendipitySideBarMenuHead, they are also affected by any style that is applied to the sidebar links, as those have no assigned class, which is why that was also one of my suggestions, and would not break prior templates. In general, however, I seriously dislike the fact that these sidebar components are constructed differently than they are in most frontend templates. It makes it that much harder, and potentially impossible, for a designer to incorporate frontend styles with backend styles.

I guess I have had the luxury of working on this new bulletproof template. S9y has really just now opened the door to decent backend styling capability - my personal opinion is - regardless of what has existed in the past - clean it up now to a) encourage backend templating and b) fix things now BEFORE there are, in fact, a lot of admin templates in circulation.

Not cleaning this stuff up seems to be very contrary to all the other efficiencies and lack of overhead elsewhere in s9y, to say nothing of how awful some of this stuff is from a programming perspective (inline styles, forced line breaks, etc).

Anyway, I'll see what I can do, including searching my s9y folders for some of these other files.

[Don Chambers]

OK - I have been beating my head against the admin index.tpl. Before I take this too far, I have already noticed some styling issues that will immediately become a problem if I proceed with a table-less structure. Here are some styles from the default admin style.css:

Code: Select all

td, th {
    font-size: 0.8em;}

table#serendipity_customfields {
    width: 100%;}

table#serendipity_customfields .customfield_name {
    background-color: #FAFAFA;
    width: 25%;
    padding-left: 5px;}

table#serendipity_customfields .customfield_value {
    background-color: #FFFFFF;
    width: 75%;}

table#serendipity_customfields .customfield_value textarea {
    width: 100%;
    height: 100px;}

Since I am currently only working on index.tpl, only the th & td styles will be affected right now. Point is, however, that once the table is gone, there will be, at minimum, some font impact in ANY admin stylesheet - both the default, as well as any template-specific admin stylesheet. Since compatibility with the past has been a huge priority (despite the tremendous inefficiencies of doing so), does this automatically kill any hope of going table-less, or does it provide another example of why this actually NEEDS to be udpated?

[garvinhicking]

Hi!

Could you maybe show an example of how the change would result? If it just enlarges the font-size a bit, I bet that everyone could live with that.

Best regards,
Garvin

[Don Chambers]

Which stylesheet is supposed to load by default? My s9y install is loading /templates/carl_contest/admin/style.css, but I noticed d_cee's is loading /templates/default/admin/style.css....

I'm having a helluva time finding the right combination of style settings that constructs the admin page the same way it exists now as a table, AND have it work across browsers AND work with existing stylesheets.

Anyone happen to have a tableless structure, single sidebar that does? Cannot float the left sidebar and have it expand to fill the AdminFrame unless the AdminFrame also floats. Same thing happens with elements within the content area. Tables, as we have now, are much more forviging. Another example: the sidebar is often set to, say, 20%, but the content area is set to 100%. That might work in a table, but is sure does not with DIVs!

I think I am beginning to understand why no one bothered converting this thing to tableless in the past!

[garvinhicking]

Hi!

Which stylesheet is supposed to load by default? My s9y install is loading /templates/carl_contest/admin/style.css, but I noticed d_cee's is loading /templates/default/admin/style.css....

The default stylesheet is the carl_contest one. d_cees should actually be loading its own style.css, in the templates/competition/admin/style.css folder!

I'm having a helluva time finding the right combination of style settings that constructs the admin page the same way it exists now as a table, AND have it work across browsers AND work with existing stylesheets.

Sigh...if it only were easier for all the browser to happily coexist.

I think I am beginning to understand why no one bothered converting this thing to tableless in the past!

Tables do have an advantage that they are harder to break than those floating divs, yeah...I actually forgot about those advantages.

Regards,
Garvin

[Don Chambers]

By d_cee's, I did not mean his competition template, I meant the one at s9y-bulletproof.com. That site is using templates/default/admin/style.css for the admin stylesheet. Am I correct in assuming that this stylesheet is loaded if the carl_contest theme does not exist?

As far as the table-less issues go, I think I am going to split my efforts into 2 pieces. First will be to add id's/classes. We can then deal with tableless if/when necessary. I can say with reasonable confidence, however, that finding a solution that works across all browsers, AND with existing admin stylesheets will likely be very, very difficult. In all probability, a decision will need to be made to a) ignore past admin stylesheets b)modify all known prior admin stylesheets or c) produce code exclusive to standards compliant browsers only.

One other thing - should the admin index.tpl have a doctype?

[garvinhicking]

Hi!

By d_cee's, I did not mean his competition template, I meant the one at s9y-bulletproof.com. That site is using templates/default/admin/style.css for the admin stylesheet. Am I correct in assuming that this stylesheet is loaded if the carl_contest theme does not exist?

Yes, exactly so.

As far as the table-less issues go, I think I am going to split my efforts into 2 pieces. First will be to add id's/classes. We can then deal with tableless if/when necessary. I can say with reasonable confidence, however, that finding a solution that works across all browsers, AND with existing admin stylesheets will likely be very, very difficult. In all probability, a decision will need to be made to a) ignore past admin stylesheets b)modify all known prior admin stylesheets or c) produce code exclusive to standards compliant browsers only.

That's a reasonable approach, I agree!

One other thing - should the admin index.tpl have a doctype?

That's a hard question. If we add a XHTML doctype, much might become differently displayed since it's not all XHTML output in the admin. If we add HTML4 doctype, this might lead to some errors with XHTML output?

Regards,
Garvin

[Don Chambers]

I tried the same {if} condition for loading the doctype that we use in the frontend, and you are correct - certain display characteristics changed, so I removed it. Guess that can also be tackled at a later date when this entire thing gets a very overdue conversion to divs.

I am progressing nicely with many of the changes I suggested several posts ago.... all in table format though. When I am done, I will zip it all together and make it available for download, or you can PM me with an email address, and I will send it there.

Each file I change contains comments identifying the change, so there will be no mystery as to what changed, and it can always be undone if need be. This also means you will need to edit every file I change to remove these same comments, but that should only take a few moments per file. If you prefer I handle this differently, let me know.

[garvinhicking]

Hi Don!

Great, many thanks for that help! A download link is easiest for me to take on the files, I prefer that to an email.

Each file I change contains comments identifying the change, so there will be no mystery as to what changed, and it can always be undone if need be. This also means you will need to edit every file I change to remove these same comments, but that should only take a few moments per file. If you prefer I handle this differently, let me know.

Since it will get committed by me with SVN tools, those will highlight any change on its own, so you don't need to mark trivial changes for me. Only those that might have some impacts on the display or where you would want specific notes. But you can also leave them intact and I'll remove them later, whatever is easiest for you.

Regards,
Garvin

[Don Chambers]

I'm nearly done Garvin. Sometimes my notes are just to identify the specific change. Others are directed to you specifically, so you will probably want to check them out in advance. I have been short on time the past few days, but will hopefully wrap all this up within the next few days.

[Don Chambers]

I've gotten adventurous with a few of my changes. I noticed both the manage users and manage groups pages had edit & delete text links while most others used serendipityIconLink, so I added that feature to both the users and groups pages. Next I wanted to add the group icon to the groups page much as is done on the users page (ie, preceed the group name with the appropriate group icon). Below is the code I was trying, but when I do it this way, it shows all my group names to be USERLEVEL_ADMIN_DESC :

Code: Select all

$i = 0;
foreach($groups as $group) {
            if ( $group['name'] = "USERLEVEL_ADMIN_DESC" ) {
                $img = serendipity_getTemplateFile('admin/img/user_admin.png');
            } elseif ( $group['name'] = "USERLEVEL_CHIEF_DESC" ) {
                $img = serendipity_getTemplateFile('admin/img/user_chief.png');
            } else {
                $img = serendipity_getTemplateFile('admin/img/user_editor.png');
            }
?>

Also, is there a description somewhere of htmlspecialchars() and serendipity_setFormToken() or can they be simply explained in terms of what they do, and when they are needed?

[garvinhicking]

Hi!

Where did you insert that code, in which file at which line? I know much of s9y's code, but your snippet is too small to uniquely identify it

Also, is there a description somewhere of htmlspecialchars() and serendipity_setFormToken() or can they be simply explained in terms of what they do, and when they are needed?

htmlspecialchars set http://php.net/htmlspecialchars. serendipity_setFormToken() is not easy to explain. It adds a input-type hidden or a GET variable that is required so that HTTP requests cannot be forged by forein users.

Regards,
Garvin

[Don Chambers]

Code was from include/admin/groups.inc.php, which creates the admin page "manage groups". Entire code portion is:

Code: Select all

<?php
if (serendipity_checkPermission('adminUsersMaintainOthers')) {
    $groups = serendipity_getAllGroups();
} elseif (serendipity_checkPermission('adminUsersMaintainSame')) {
    $groups = serendipity_getAllGroups($serendipity['authorid']);
} else {
    $groups = array();
}
$i = 0;
foreach($groups as $group) {
            if ( $group['name'] = 'USERLEVEL_ADMIN_DESC' ) {
                $img = serendipity_getTemplateFile('admin/img/user_admin.png');
            } elseif ( $group['name'] = 'USERLEVEL_CHIEF_DESC' ) {
                $img = serendipity_getTemplateFile('admin/img/user_chief.png');
            } else {
                $img = serendipity_getTemplateFile('admin/img/user_editor.png');
            }
?>
<div class="serendipity_admin_list_item serendipity_admin_list_item_<?php echo ($i++ % 2) ? 'even' : 'uneven' ?>">
<table width="100%">
    <tr>
        <td><img src="<?php echo $img ?>" alt="" style="border: 0px none ; vertical-align: bottom; display: inline;" /> <?php echo htmlspecialchars($group['name']); ?></td>
<td><?php echo htmlspecialchars($group['id']); ?></td> 
        <td width="200" align="right"> <a href="?serendipity[adminModule]=groups&serendipity[adminAction]=edit&serendipity[group]=<?php echo $group['id'] ?>" title="<?php echo EDIT . " " . $group['name']; ?>" class="serendipityIconLink"><img src="<?php echo serendipity_getTemplateFile('admin/img/edit.png'); ?>" alt="<?php echo EDIT . " " . $group['name']; ?>" /><?php echo EDIT ?></a>
                                       <a href="?serendipity[adminModule]=groups&serendipity[adminAction]=delete&serendipity[group]=<?php echo $group['id'] ?>" title="<?php echo DELETE . " " . $group['name']; ?>" class="serendipityIconLink"><img src="<?php echo serendipity_getTemplateFile('admin/img/delete.png'); ?>" alt="<?php echo DELETE . " " . $group['name']; ?>" /><?php echo DELETE ?></a></td>
    </tr>
</table>
</div>
<?php
    }
?>

In the code above, I have already modified the original to show the edit & delete serendipityIconLink images, rather than just simply text links. That works fine.

Next, I am trying to include an icon before each group name, much as it is shown when viewing "manage users". When using the code piece above, all of my groups are shown as USERLEVEL_ADMIN_DESC. If I do not use that "if ( $group['name'] =...." piece, the resulting table correctly shows each individual group name. Let's get this issue resolved first, then I'll get back to htmlspecialchars and serendipity_setFormToken later.

I'll

[garvinhicking]

Hi!

In PHP you must do comparisons with "==" and not "=". The latter ASSIGNS a variable, which is why you change $group['name'] to a different thing everytime you compare it

HTH,
Garvin

[Don Chambers]

Thanks Garvin. That helped, but perhaps I am not using the correct variable. I now have this:

Code: Select all

$i = 0;
foreach($groups as $group) {
            if ( $group['name'] == 'USERLEVEL_ADMIN_DESC' ) {
                $img = serendipity_getTemplateFile('admin/img/user_admin.png');
            } elseif ( $group['name'] == 'USERLEVEL_CHIEF_DESC' ) {
                $img = serendipity_getTemplateFile('admin/img/user_chief.png');
            } else {
                $img = serendipity_getTemplateFile('admin/img/user_editor.png');
            }
?>

It is no longer changing each group name, but everything is evaluating to the final else statement as only that icon is shown for each group name. What else am I missing?