garvinhicking wrote:The version_compare logic is a bit strange, so you might want to read the PHP.net documentation and ESPECIALLY the user notices there for some example codes.
Expect a desperate cry for help if I'm unable to understand it
BTW: Remember back in the day when we first started using the code for the customizable navbar? Some templates still have code like this, i.e. andreas09:
Code: Select all
{if $head_version < 1.1}
<!-- ****** Change navbar links here ****** -->
<li><a href="#">About</a></li>
<li><a href="#">Photos</a></li>
<li><a href="#">Music</a></li>
<li><a href="#">Contact</a></li>
{else}
...
So is there a good reason not to use this:
Code: Select all
{if $head_version < 1.4} ... {else} ... {/if}
other than "it wouldn't work with a beta version? (And please don't ask me why I didn't remember this earlier - I don't know
)
garvinhicking wrote:Maybe there's a way to change 1.4 so that those problems are less likely to appear?
Yes, there is, but we don't want to take that way. It would be to revert all the (necessary, long overdue!) changes I made to the emitted HTML code in the core plugins. You remember "operation havoc", right? When we decided to do those changes, we were aware of the issues it might cause with older templates (older templates meaning: everything created before the changes), which is why I went through all the core templates as well, adding changes to the style.css files.
However, there are a lot of templates which are not in the core and have not been adapted to these changes. Most of them are also much more sophisticated than the templates shipped with s9y, especially in terms of CSS.
garvinhicking wrote:Which changes exactly cause the trouble?
Well, the WP Premium thread in the German forum is a good example. WP Premium uses a lot of CSS wizardry to compensate for the fact that some of the core plugins emitted, let's just say it, HTML which wasn't semantically correct. Now that these plugins emit the correct HTML (in this case: an ul), the CSS doesn't produce the intended result.
Then again, WP Premium is a WP port, which in this particular example is kind of also the reason why the new code isn't working: The original's stylesheet wasn't created for an ul which also has the XML icon we use in the syndication or list of authors sidebar plugin. (My rambling must sound pretty confusing. Hang in.)
So maybe I'm being a little
too careful here. A lot of templates will work just fine with some minor changes to the style.css. The number of templates where issues like in WP Premium will surface is probably rather small. It will also probably be almost only WP ports.
garvinhicking wrote: We must evaluate if the trouble that it introduces is worth the benefit the changes provide.
By any means, yes, it is worth the benefit! Having plugins which emit strange, non-semantic HTML is
not the way to go! We have to follow that road of editing the HTML code s9y emits to semantically sound HTML by any means, even if it means that some templates will look funny until we provide fixes for them!
(Which is why I was actually suggesting the version-dependant CSS files: So we can ensure backwards compatibility for those users who can't choose to switch to the latest version, but do have access to the latest version of a template.)
Actually, I have one or two things in mind to change in the HTML the core emits, for example the code for inserting images from the media db. But that can and will have to wait until after the 1.4 release
YL
