Styling the Backend!

[garvinhicking]

Hi!

For Serendipity, only the frontend (what the visitors see) could be subject to Smarty-Templating. One reason for not utilizing these features in the backend was to maintain stability, ease of change for core developers and reduce migration woes so that the Admin Backend would always be accessible.

What we have now added to the Serendipity 1.2 snapshots (that will soon become public beta and a final release in late Summer) is functionality that allows you to template the backend layout as well as the 'New/Edit Entry' screen. Other functions like category manager, plugin manager etc. will remain hardcoded and eventually changed, because most of their look can already be controlled with CSS only.

To maintain stability and prevent migration problems where Smarty might not be initialized, Serendipity can fall back to the usual PHP-only backend. This is done using a tricky session variable scheme - when Smarty cannot be loaded, a session variable is set, and on the next page call, this variable will force the Serendipity framework to use the fallback routines. Nifty stuff.

Please try out the new theming possibilites and give feedback. The default admin stylesheet can be found in the templates/default/admin/index.tpl and templates/default/admin/entries.tpl templates, and can be copied to your own theme directory as usual.

The change has just been committed to SVN and should be contained in snapshots starting as of tomorrow.

Regards,
Garvin

[Don Chambers]

Garvin - is there any chance (please, please, please) that the core php output can be streamlined a bit prior to the 1.2 release? I'm pulling my hair out looking at all the inline styles (colors, borders, sizes, etc), &nbsp's, HTML <br>'s, and XHTML's <br />, <strong>, etc, etc, etc. Even the footer falls below what is otherwise all contained by a table. Also numerous examples of elements that would benefit from a defined class, yet have none. No offense, but this portion of s9y looks to have been seriously neglected for a long time, and I am wondering if it is worth my time to work up an admin stylesheet aimed at the current condition of the html if, by any chance, a significantly cleaner version is in the works.

Also, what other php files generating html output are used by the admin suite? The default admin stylesheet contains a number of defined classes I simply cannot find in serendipity_admin.php.

[garvinhicking]

Hi!

If one would like to prepare a patch for how it should be, I'm willing to commit this. As long as it doesn't break any browser.

The default HTML is suited for the default admin theme, that much is true. In the admin we have much higher requirements for tight and exact spacing, so this is the reason why it's not as clean as the frontend is.

Also, what other php files generating html output are used by the admin suite? The default admin stylesheet contains a number of defined classes I simply cannot find in serendipity_admin.php.

All admin HTML functionality should be contained in the include/admin/*.php files.

Best regards,
Garvin

[Don Chambers]

Any chance you can provide an example of where this tight & exact spacing is so critical, and why that has to occur in the manner it exists now, instead of through css?

I do not know if I can tackle this issue or not. Stripping out all the inline styles, forced line breaks, etc means there is no way the admin interface will function perfectly UNLESS the default admin stylesheet is also modified.

[garvinhicking]

Hi!

Any chance you can provide an example of where this tight & exact spacing is so critical, and why that has to occur in the manner it exists now, instead of through css?

If we remove some of the inline styles it means that it would require to check if all existing backend style.css files still work as intended. So I can't really tell you what would break, because it would need to be tested.

It's a hard job to do, the admin panel is full of inline styles that I could spend a week on cleaning that up. Which is time that I don't have for a task where in the end you don't see any change (if done right).

Maybe it would be better to only tackle/address those inline styles that you currently have problem with styling? Maybe that adds up to fewer than to generally strip out each and every single one of them.

Best regards,
Garvin

[Don Chambers]

I am a little less concerned by inline styles pertaining to things that can be overridden with css !important, and more concerned by <br>'s and <br />'s, and other hard coded elements. Perfect example: The footer div is separated from the table by a <br />. This means I either cannot position the footer directly under the table, or I have to use trickery to accomplish it, which will never look exact from one browser to another. The mere fact the footer exists as a div below the table is strange anyway - why not simply make it a row/cell in the table? Start applying borders to both and it gets really challenging to keep both elements the same width.

Stripping out BR's would require a lot of elements to pick up display: block. I have not looked closely enough to determine if that is ALL that would be needed, or if you are using those BRs for other purposes.

I might be able to find examples of where an id or class would be beneficial to add. Those are probably easy additions, since their prior lack of existence would not break older stylesheets.

[garvinhicking]

Hi!

Some of the <br /> could be addressed with "display:none" maybe?

The footer was placed there in an div in an effort to reduce tables in the backend to a bare minimum

But the footer can now be changed with the backend smarty templating, so that's not a problem anymore, you could remove that.

Thanks for diving into this. It does need work and retouching!

Regards,
Garvin

[Don Chambers]

Display:none on the <br>s was my first instinct, and it works well on the admin frontpage, but falls apart quickly elsewhere..... they are being used everywhere! There simply is not not enough styling to single out certain BRs from others. Also not liking the use of &nbsp.

As for the single footer div outside the table, I hardly see how that is stripping the table down to bare minimum. And it makes absolutely NO sense that it would be separated from the table with a <br />. If this entire page HAS to be a table, probably better for the footer to merely be the final row in the table, and I doubt that change would affect any existing admin template. Personally, I would love to see all BR's, &NBSP and any similar forced characters removed regardless of what they do to the few existing admin stylesheets. There just are not that many out there, and they can be easily patched with css.

So, is the default html rendering now coming from templates/default/admin/index.tpl or is it still being generated by a php file? I looked briefly at the other include/admin/*.php files..... to say the least, it would be a monumental task to clean up what is accessible right now (index.tpl & entries.tpl), and despite that cleanup, there is plenty that is not open to templating that would still be generating tables (bad enough) missing lots of useful classes, but containing these nasty forced line breaks and other junk better handled with css.

Anyway, I am reluctant to create a template specific tlp for the very reasons you discussed on the bulletproof thread - that being the very real probability that the template would require frequent updating to accomodate new features...... I will try to keep some notes on things that look like they can be added or easily modified. Maybe some of those can find their way into the default prior to 1.2 full release.

[garvinhicking]

Hi!

Sure, if someone cleans up the HTML, I don't mind

So, is the default html rendering now coming from templates/default/admin/index.tpl or is it still being generated by a php file? I looked briefly at the other include/admin/*.php files..... to say the least, it would be a monumental task to clean up what is accessible right now (index.tpl & entries.tpl), and despite that cleanup, there is plenty that is not open to templating that would still be generating tables (bad enough) missing lots of useful classes, but containing these nasty forced line breaks and other junk better handled with css.

Only the basic layout comes frmo the .tpl file. All CONTENT is still created within the *.php files.

Yes, it's a lot to do. Which is the reason why it hasn't been done yet.

Also, the benefits from that are currently very weak, so I still have a large list of other things to waste my time with

Best regards,
Garvin

[Don Chambers]

Trust me Garvin - your efforts are HUGELY appreciated, and nothing in this series of posts from me is meant to suggest you have been sitting on your @$$ doing nothing!! I am well on my way to figuring out what all the classes are that currently exist in the default stylesheet. At least, I think I am working with the default. Anyway, I do have a question. is the class .direction_rtl ever used? I'm curious why you even had the two different directions in the first place. I have never seen anything positioned using that property.

[garvinhicking]

Hi!

I believe the directio_rtl was added at some point where I thought it might be needed for future templates where we need to position strings ltr or rtl specifically. It seems that didn't happen, so yes - the class is not used anywhere.

Best regards,
Garvin

[Don Chambers]

Thanks Garvin. Moving on..... I took a quick look at everything. Keep in mind, I am far from an expert, and this was only a cursory review.

1) Add class to "welcome back Author Name", or at minimum, wrap within a <h2> or <h3> tag.

2) Add class to "No Large Preview". Wrap in <p>???

3) Add class to each type of input (select, text, textarea, radio, etc). Buttons already have a class of .serendipityPrettyButton but css applied to "input" currently affects button as well.

4) Add class to serendipity_plugin_config for option title where it currently generates <strong>. (ie, <td style="border-bottom: 1px solid #000000; vertical-align: top"><strong>Config Option Title</strong>)

5) Convert all table structures to DIVs.

6) Remove all instances of <br> and <br />. Add classes styled as display: block to compensate. <p> might also work.

7) Remove all instances of &nbsp unless absolutely required to separate some element. Definitely remove it as the first character of template options description. Possibly replace with inline style of padding-left.

8 ) If not converted to DIV, move footer into table structure as bottom row.

9) Add class to DIV containing "manage tags".

10) .serendipity_admin_list_item.serendipity_admin_list_item_even & .serendipity_admin_list_item.serendipity_admin_list_item_uneven are used in various places. In at least 2 instances (list of available templates, and the list of entries), "even" is assigned to the first in the list, uneven to the next, etc. In other words, it is exactly backwards from what would be expected (ie, 1, 3, 5 are odd, yet assigned to class "even").

11a) Why is admin sidebar titles an li? <li class="serendipitySideBarMenuHead">{$CONST.ADMIN_ENTRIES}</li>
Wouldn't this be better as <h3 class="serendipitySideBarMenuHead">{$CONST.ADMIN_ENTRIES}</h3> followed by the <ul>?

11b) From a consistency perspective, it would also be nice to see this constructed the same way as a frontend sidebar:

Code: Select all

<div id="serendipitySideBar">
	<div class="serendipitySideBarItem">
		<h3 class="serendipitySideBarMenuHead"></h3>
		<ul class="content">
			<li class"serendipitySideBarMenuLink">
			</li>
		</ul>
	</div>
</div>

12) The input button within td .serendipity_pluginlist_header does not have the serendipityPrettyButton class most other buttons do. Neither does the "Save" button on the "Personal Settings" page. Might be other buttons missing this class. Suggest cursor: pointer for the pretty button class.

13) I believe the default stylesheet has an error in a class name. Stylesheet has .serendipityAdminMsgNote..... should this be .serendipityAdminMsgNotice???

[garvinhicking]

Hi!

Could you maybe provide a unified diff/patch for your suggestions? This would allow me to easier implement your changes.

I'm currently quite busy with creating something special for Serendipity, and don't have the time to really dig into this.

11a) Why is admin sidebar titles an li? <li class="serendipitySideBarMenuHead">{$CONST.ADMIN_ENTRIES}</li>
Wouldn't this be better as <h3 class="serendipitySideBarMenuHead">{$CONST.ADMIN_ENTRIES}</h3> followed by the <ul>?

This would interfer with the rendering of all exsisting admin templates.

.serendipityAdminMsGNote
[/code]

This class is used by the installer/configuration tool.

The things you've mentioned are very great! I think appart frmo the one above, all of them could be solved without affecting the current layout in browsers! Would be awesome if a patch for this could be constructed.

Best regards,
Garvin

[Don Chambers]

I might have a shot at the admin index.tpl. However, the vast majority of my suggestions are not contained there - they are generated by the content, and I would not know where to go looking for them.

This would interfer with the rendering of all exsisting admin templates.

A lot of this would interfere with any existing admin template - but is that really a HUGE issue at the moment? There just are not that many. I only know of 2 - yours, and carl's.

.serendipityAdminMsGNote

This class is used by the installer/configuration tool.

Well, when a admin attempts to install a new sidebar plugin, for example, the responding code before the plugin list is displayed uses a class of serendipityAdminMsgNotice, which is not contained in any css file. Here is the HTML:

Code: Select all

<div class="serendipityAdminMsgNotice">Trying to open URL <a href="http://netmirror.org/mirror/serendipity/package_sidebar_en.xml">package_sidebar_en.xml</a>...</div>

So, I thought it could be an error. Maybe you should convert that class to the same one used by the installer.

I'm currently quite busy with creating something special for Serendipity...

Oh REALLY??!!! Little hint?????

[garvinhicking]

Hi!

I might have a shot at the admin index.tpl. However, the vast majority of my suggestions are not contained there - they are generated by the content, and I would not know where to go looking for them.

You could try a simple fulltext search with your editor on all files? I'm using linux, and whenever I search something I use:

Code: Select all

find -exec grep -i -l -d skip 'serendipityAdminMsgNote' {} \;

and then it shows me where to look into.

This would interfer with the rendering of all exsisting admin templates.

A lot of this would interfere with any existing admin template - but is that really a HUGE issue at the moment? There just are not that many. I only know of 2 - yours, and carl's.

But this would really mess up the whole display of the admin menu bar, this is not acceptable. And never forget about people who create their custom themes based on the admin panel on their own, without sharing their templates.

This menu structure has been around for nearly 3 years. I'm quite sure that many people wrote custom stylesheets for the menu rendering...

Well, when a admin attempts to install a new sidebar plugin, for example, the responding code before the plugin list is displayed uses a class of serendipityAdminMsgNotice, which is not contained in any css file. Here is the HTML:

Code: Select all

<div class="serendipityAdminMsgNotice">Trying to open URL <a href="http://netmirror.org/mirror/serendipity/package_sidebar_en.xml">package_sidebar_en.xml</a>...</div>

Ah. This is output only of the spartacus plugin, it uses this CSS class for future compatibility already, since it's not a Notice that should be formatted like the notice in the admin installer.

Oh REALLY??!!! Little hint?????

It currently involves about 297.491 characters and is still growing.

Regards,
Garvin