Page 1 of 2
Let's just smartify the whole thing
Posted: Mon Apr 07, 2008 9:41 pm
by yellowled
I realize there may be reasons why not every single plugin which creates a piece of HTML in s9y is smartified. Performance, backwards compatibility etc. But I am encountering more and more cases in creating or porting templates where I find myself cursing at the fact that some plugin is not smartified.
Take the archives plugin (the one shipped w/ s9y) for example - I'm sorry, but the code it creates is simply deprecated, period. It's a lot of anchors seperated by line breaks, which just screams "unordered list". Maybe it didn't scream that at the time the code was implemented in the plugin, but nowadays it does. Unfortunately, I cannot simply change it to an unordered list.
I could of course modify the code in the plugin's PHP code. But there's not much sense in doing that because it will be overwritten in the next update.
Again, I realize it's probably not a good idea to smartify every little plugin we have, but how about giving people the option to use a .tpl file? The categories plugin has an option to use a .tpl file - it would be really awesome if one day all plugins creating HTML code would have this option, too.
I also realize this involves a lot of work, but I honestly think that we're bound for stagnation in terms of templates and code if we keep clinging to deprecated HTML. I'm not a coder, so I'm uncomfortable with editing code I don't understand to it's full extent, but I'm offering to help with creating those .tpl files.
Smarty is one of the biggest assets we have. Let's use it.
YL
Posted: Mon Apr 07, 2008 9:59 pm
by Don Chambers
Well said, and I agree 100% with everything you said YL!!!
The more I work with smarty files, the more I find myself needing/wanting to modify the standard output of some of these sidebar plugins that are not currently "smartified".
Two key plugins that I have been campaigning for are recent entries (high priority), and recent comments (medium priority).
If the archive plugin was smartified, I would definitely provide exactly the same structure you are thinking of - ordered, or unordered list.
Posted: Mon Apr 07, 2008 10:25 pm
by judebert
For the casual blogger, Smartifying everything is overkill. But for everyone else, Smarty is required. Why?
First there's the point that YL implicitly made: standards change. Back when Garvin-knows-who created the archives plugin, CSS was likely very little used. A break-separated list of anchors was expected; a list would have been ridiculous. Now we expect the unordered list styled in a separate file. What will the future bring? We can't tell for sure, but Smarty can provide it in a backwards-compatible way that PHP alone simply cannot.
Then there's his explicit point: Smarty is one of our greatest assets. BOTH of our competitors have created their own templating systems, and spent a lot of effort at it. Using them takes experience and dedication. Sometimes simply changing the theme can require modifying files on the server. Not us! Even our casual bloggers can customize their templates with a single click, while the more dedicated can create anything they desire by copying pieces of other templates around.
Except for those plugins that don't support it.
I like the idea of a per-plugin Smarty option. I must admit that I'm not expert with Smarty yet, and I don't know how much of performance penalty we would pay, or if that hit could be mitigated with caching. But making it an option eliminates all those considerations. If you're willing to take the hit, turn on the templating. Can't stand the heat? Turn it back off.
Certainly, at some point, we need to release a version of Serendipity that discards its backwards cousins. A s9y that throws off the cruel shackles of unwavering history. A clean, lean, blogging machine.
Don't we?
I hope so. Until then, I will code towards that day, providing you templateers the Smarty you desire whenever I can.
Posted: Tue Apr 08, 2008 10:45 am
by garvinhicking
Hi!
Okay, you beat me. If someone wants to implement optional templates for any of the plugins we have (like categories plugin), I'm fine with adding that to 'vanilla s9y'.
But basically I'm more in favor of turning the HTML output of those tiny default plugins so that it's nice HTML markup. I'm just afraid it might break terribly on blogs with older templates. Could someone check how odd a s9y blog would look like if archives, for example, where turned to unordered lists? That would look like the cleaner approach to me...
Regards,
Garvin
Posted: Tue Apr 08, 2008 11:28 am
by yellowled
garvinhicking wrote:Okay, you beat me. If someone wants to implement optional templates for any of the plugins we have (like categories plugin), I'm fine with adding that to 'vanilla s9y'.
But basically I'm more in favor of turning the HTML output of those tiny default plugins so that it's nice HTML markup. I'm just afraid it might break terribly on blogs with older templates.
Another idea would be to give users three options in the plugin configuration: a) use the "traditional" code (for really old templates), b) use the "modern" code, and c) use a tpl file at the risk of slower performance
That would probably be the safest bet. On the other hand, it means a looot of configuring, and it also blows up the code of those plugins significantly.
garvinhicking wrote:Could someone check how odd a s9y blog would look like if archives, for example, where turned to unordered lists?
I'll set up a vanilla 1.3 installation later and check it out.
YL
Posted: Tue Apr 08, 2008 12:02 pm
by garvinhicking
Hi!
Another idea would be to give users three options in the plugin configuration: a) use the "traditional" code (for really old templates), b) use the "modern" code, and c) use a tpl file at the risk of slower performance
Hm, I don't really like this. Too complex, too high "WTF"-Factor. We should really try to get rid of the old bad code.
Regards,
Garvin
Posted: Tue Apr 08, 2008 12:14 pm
by yellowled
garvinhicking wrote:Too complex, too high "WTF"-Factor.
Well, the whole "WTF" factor of this is probably enormous, anway. Love that word, BTW
garvinhicking wrote:We should really try to get rid of the old bad code.
Yes, we should. So I set up a vanilla s9y 1.3 installation on my localhost, edited the code for archives and syndication, and took screenshots along the way. There you go:
With Serendipity 2.3 (I figured that's as old as they get):
-
http://yellowled.de/tmp/fresh_install-default.png
-
http://yellowled.de/tmp/edited_plugins-default.png
With carl_contest, the current standard template:
-
http://yellowled.de/tmp/fresh_install-carl_contest.png
-
http://yellowled.de/tmp/edited_plugins-carl_contest.png
Yes, there is a difference, but I don't think it's that bad, especially if you take into account that I didn't use
any inline styles. Both edited plugins use an <ul> without any further inline styling.
Using something like <ul style="list-style: none;"> and <li style="margin-left: 0;"> instead, one wouldn't even see the difference. However, I would advise
not to use inline styling. Here's why: Inline styles are a pain in the rear end. I realize they would make it much easier to maintain backwards compatibility, but I honestly think that's taking one step forward, two steps back.
YL
Posted: Tue Apr 08, 2008 12:19 pm
by garvinhicking
Hi!
Fine with me. Let's go and wreak havoc with the old HTML. The breakage is acceptable. For the default/carl-contest/bulletproof templates coming with s9y 1.4, we can adapt the look. Users with old stylesheets will have to update then, and we can fix existing templates that look butt-ugly in the future.
But it's not worth living with the old HTML code anymore, I agree.
BTW, I still want to use BP as default for 1.4. I'm just waiting for Don to check in the carl-look-alike-colorset to BP to make the switch.
I also dislike inline styles in the plugin output, let's keep that out. Objections?
Regards,
Garvin
Posted: Tue Apr 08, 2008 1:05 pm
by yellowled
garvinhicking wrote:Let's go and wreak havoc with the old HTML.
How do you want to tackle this? Should we post suggestions for the new code here? I really don't feel comfortable editing the core files in svn/cvs ... Also, should we start with the core plugins shipped w/ s9y and then work our way through the additional plugins?
garvinhicking wrote:Users with old stylesheets will have to update then, and we can fix existing templates that look butt-ugly in the future.
I'm fine with editing old templates, but I guess we should complete wreaking havoc first.
garvinhicking wrote:BTW, I still want to use BP as default for 1.4. I'm just waiting for Don to check in the carl-look-alike-colorset to BP to make the switch.
Uhm, I think we haven't touched or looked at that in quite a while ...
YL
Posted: Tue Apr 08, 2008 2:13 pm
by garvinhicking
Hi!
How do you want to tackle this? Should we post suggestions for the new code here? I really don't feel comfortable editing the core files in svn/cvs ... Also, should we start with the core plugins shipped w/ s9y and then work our way through the additional plugins?
New code suggestions are welcome, yes. But don't be afraid, we have version control, you can't really screw up things
And yes, I think priority belongs to the s9y bundled plugins.
Regards,
Garvin
Posted: Tue Apr 08, 2008 2:51 pm
by yellowled
garvinhicking wrote:New code suggestions are welcome, yes. But don't be afraid, we have version control, you can't really screw up things

I am aware of that, thanks

My problem is I'm still not very familiar with CVS (which isn't really a problem until we start attacking the additional plugins, which we definitely will have to, too) or PHP (the code I used to make the syndication plugin use an ul is probably horrible at best), so I'd much rather suggest code changes and let someone who actually knows what he's doing supervise it. However, I know this probably means a lot of editing for you. Sorry
garvinhicking wrote:And yes, I think priority belongs to the s9y bundled plugins.
Okay, so we should probably start with the internal plugins, followed by those in /plugins. Let's see what /include/plugin_internal.inc.php has in store for us ...
*
serendipity_calendar_plugin - that's actually one I really hate, but it is already smartified, so we don't have to touch it at all
*
serendipity_quicksearch_plugin - I don't think we have to touch that, either; BP and other templates show how to put it into the header or something, and it doesn't need any code changes in my humble opinion
*
serendipity_archives_plugin - that should really be an ul; let's see, if I'm right, this is the code that generates the HTML output:
Code: Select all
if (!$hidden_by_zero_count) {
echo '<a href="' . $link . '" title="' . $ts_title . '">' . $ts_title . $html_count . '</a><br />' . "\n";
}
}
echo '<a href="'. $serendipity['serendipityHTTPPath'] . $serendipity['indexFile'] . '?frontpage">' . RECENT . '</a><br />' . "\n";
echo '<a href="'. serendipity_rewriteURL(PATH_ARCHIVE . $add_query) .'">' . OLDER . '</a>'. "\n";
}
I think it would suffice to just put all those links into <li>s of an <ul> and get rid of the <br />s, like this:
Code: Select all
echo '<ul>' . "\n";
if (!$hidden_by_zero_count) {
echo '<li><a href="' . $link . '" title="' . $ts_title . '">' . $ts_title . $html_count . '</a></li>' . "\n";
}
}
echo '<li><a href="'. $serendipity['serendipityHTTPPath'] . $serendipity['indexFile'] . '?frontpage">' . RECENT . '</a></li>' . "\n";
echo '<li><a href="'. serendipity_rewriteURL(PATH_ARCHIVE . $add_query) .'">' . OLDER . '</a></li>'. "\n";
echo '</ul> . "\n";
}
I hope this is correct, but please check it
*
serendipity_topreferrers_plugin, serendipity_topexits_plugin - I don't see any HTML being generated here ..?
*
serendipity_syndication_plugin - that should be an ul, too; just replace every "div style="padding-bottom: 2px;" with "li" and every "/div" with "/li"; obviously, it also needs <ul> and </ul>, but I'm not sure where to put those and how
*
serendipity_superuser_plugin - the code is okay, it's just an anchor
*
serendipity_plug_plugin - that's our logo, right? I'd probably opt to put the text link in <p></p> instead of <div></div>, but that's really not essential
*
serendipity_html_nugget_plugin - nothing to change here
*
serendipity_categories_plugin - smartified already with an option to no use the smartified code; personally, I can live with that, and I don't think it's worth changing anything here
*
serendipity_authors_plugin - hmmm; I'm not sure about that one, I have to install it and take a look at the code first
See? It's not even that much to edit
YL
Posted: Tue Apr 08, 2008 3:03 pm
by yellowled
yellowled wrote:* serendipity_authors_plugin - hmmm; I'm not sure about that one, I have to install it and take a look at the code first
Yup, should be an ul, too. Let's see ... it should definitely be an ul, no matter if it's a form or not. Every "div style="padding-bottom: 2px;" should be replaced by "li", same for the closing divs. Also needs <ul> and </ul>, of course. But if it's a form, the submit button and all authors link should no be included in that unordered list. However, it's probably a better idea to put those in <div>s or <p>s.
Code: Select all
if ($is_form) {
$html .= '<div class="serendipity_authors_submit"><input type="submit" name="serendipity[isMultiAuth]" value="' . GO . '" /></div>';
}
$html .= sprintf(
'<div class="serendipity_authors_allauthors"><a href="%s" title="%s">%s</a></div>',
Somethink like this, I guess.
YL
Posted: Tue Apr 08, 2008 3:28 pm
by garvinhicking
Hi!
I suggest preparing a larger diff, I will not have the time to implement this "on the fly", I do not have sufficient time for that the next 2-3 months.
Maybe Don oder Judebert can be of help, if not, I can try to implement your findings once you think you're finished
Best regards,
Garvin
Posted: Tue Apr 08, 2008 4:02 pm
by Don Chambers
garvinhicking wrote:Okay, you beat me.
OK - who are you and what have you done with Garvin??!!!
I'm pleased to hear that the concept of doing what is right to clean up stuff from the past is being embraced moving forward. In fact, I like that even more than the possibility of smarifying some of these plugins.
RE: BP, I think the front end is OK, but I do want to change the graphics slightly in the backend, then (unfortunately) switch to the fluid admin version as default due to the possibilty of the fixed width version breaking with really long, unbreakable strings, such as full path/filenames. Once that is all done, I'll check it in.
Is there a document somewhere that breaks down the basics in terms of getting a plugin to use a tpl if it exists, or can you suggest a relatively simple plugin demonstrating the functionality so we can attempt to grasp the concept?
Posted: Tue Apr 08, 2008 4:13 pm
by judebert
garvinhicking wrote:Maybe Don oder Judebert can be of help, if not, I can try to implement your findings once you think you're finished :-)
I'm on board! I'm facing some frightening deadlines at work, but I'll tell Eri we need to stop watching Dr. Who during the evenings: I have to save the day!
Handling the CVS is no big deal. I assume we're doing all this on the trunk, for the new 1.4 version when it's released? (I dislike copying changes to branches.)
Don: if nobody else does, I'll outline how to Smartify a plugin later this evening.