Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
base64 encoding of css
For whatever reason, the stylesheets inside TXP are encoded in base64. This is a mild impediment on at least these counts:
- plugins that search the admin side for stuff (e.g. smd_where_used) can’t look at stylesheets in the database without doing some special extra coding
- stylesheets take up more space in the database
- it has possible performance impacts (I have no concrete data to back this up, but since it’s another function call that needs to be made when viewing, editing and saving stylesheets it must have some kind of performance penalty, however small)
Ruud gave his thumbs up to the notion of abolishing the base64 step (and I’d like to get rid of it too), but making this change in a backwards-compatible manner is not trivial. Well, from TXP’s perspective it is fairly easy, but from a plugin perspective it presents problems.
On upgrade it’s easy for TXP to check if the stylesheets are encoded and resave them without encoding — I’ve done it and it works well. But then rvm_css will break. And jmd_img_selector will need updating. I don’t know about hcg_templates; I’m sure there are other plugins that are affected. Is this a problem? Is there a way to handle it such that it doesn’t swallow stylesheets / kill your site if a plugin is given a non-base64-encoded block of code?
One potential way that wet suggested of handling it might be to rename the database column from its current css to something else. This would mean that existing plugins will generate an error if they try to write to it, which is perhaps preferable to silently trying to base64_decode plaintext and mangling your stylesheets without warning. An alternative is for plugin authors to update their plugins to check whether they’ve been given base64 or not (there’s a regexp to do that). But this adds complexity and weight to plugins for no gain and since the whole point of rvm_css (for example) is pure speed, this step seems counter intuitive.
So I’d like to gauge:
- which plugins will be affected1
- if the benefit of changing the core outweighs the plugin fallout that it generates
- if anyone can think of a good way of making this change as unobtrusive as possible
Please post your thoughts here. Thanks in advance.
1 EDIT: Known affected plugins:
rvm_css: updated, thanksrah_css_embed: updated, thanks- jmd_img_selector : will be updated by jm soon
- fla_style_switcher / fla_altstyle_link : no longer supported (see smd_style instead)
- ako_cssParse : no longer supported by author (see smd_style or rah_css_parse instead)
- cnk_versioning
- smd_style
- smd_where_used (enhancement required to search stylesheets)
Last edited by Bloke (2010-07-05 01:18:49)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: base64 encoding of css
The base64 decoding in rvm_css only happens if you update the stylesheet on the admin side, not when loading the style sheet (static file) on the public side, so there’s no impact on speed. I don’t mind updating my plugin to support both situations.
Which regex did you have in mind? This one: ^[a-zA-Z0-9/+]*={0,2}$
I’d vote for updating the data inside the css column instead of creating a new column.
Offline
Re: base64 encoding of css
ruud wrote:
…there’s no impact on speed. I don’t mind updating my plugin to support both situations.
OK, that’s good to know. Brilliant, thanks. I know jmd_img_selector just has some css inside it that’s encoded prior to insertion into the txp_css table upon plugin installation so that may require version detection or a new plugin version for 4.3.0 and higher. Be interesting to find out if there are any other well-used plugins that might explode.
Which regex did you have in mind? This one:
^[a-zA-Z0-9/+]*={0,2}$
Yup, that’s the only one I could find that the consensus concluded was well tested and reliable enough for base64 detection.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: base64 encoding of css
updated plugin: rvm_css
Offline
Re: base64 encoding of css
Does that cope with both Ruud?
I’m presuming this will go through SVN first. I’m thinking that this is exactly the type of update where the pros of being “up-to-date” are outweighed by the cons of potential “f**k-up” via the odd plugin or two so I wouldn’t go with this one on my live sites until I knew it had been proven. That being the case I would go with installing to XAMPP and installing plugins to find out which work and which don’t then report back here so we can inform the relevant plugin writers that they will need an update.
If that’s the case we need volunteers.
Last edited by thebombsite (2009-12-20 00:16:14)
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: base64 encoding of css
Yes, it copes with both situations, so you can install it on current TXP versions as well.
Offline
Re: base64 encoding of css
I want to say, I love you… wait that was not it. Oh yes, updated rah_css_embed.
Offline
Re: base64 encoding of css
Many thanks to the authors who have updated their plugins or contacted me to say they will do so. This community rocks!
Once jm has updated jmd_img_selector I’ll commit the patch because I think that’s the last major hurdle (besides smd_style which is going through a revamp too).
Anyone who uses ako_cssParse please speak up. Adrian does not have the time to support it any more so if anyone needs it I’ll adopt it and make the necessary changes. smd_style has this functionality built in, but if you don’t want the fully fledged stylesheet switching capability of smd_style and would prefer to just be able to use TXP tags in your stylesheets, let me know.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: base64 encoding of css
From old ashes rah_css_parse with updated base64_decoding.
Last edited by Gocom (2010-01-10 15:28:03)
Offline
Re: base64 encoding of css
Gocom wrote:
From old ashes rah_css_parse
Brilliant, thanks Gocom. Saves me a job :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: base64 encoding of css
Thanks for the email Stef!
I’m going to update cnk_versioning to handle this, but I’m struggling with a simple question:
How to detect encoding when no css data is stored in the database? (When using cnk_versioning some might delete all css styles to begin a new design from scratch…)
Offline
Offline