smd_admin_themes: Manage, edit, switch and share admin-side themes

thebombsite · 2010-02-07 15:35:30

Now call me a liar. I’m too grounded to care. ;)

There have been 2 major changes with my host over recent months. First off, I host with a reseller which I haven’t changed, but they have moved host themselves which effectively means I have. Second, my server was PHP4.* based although I could call up PHP5.* with a bit of .htaccess magic but it is now fully PHP5.* plus MySQL 5.* as well (not sure if that makes any difference).

Anyway it would seem that somewhere amongst that lot certain PHP facilities I was previously denied have now been enabled. What it all means is that I can now import .zip, .tar and .tgz files. Whoopee!

I can’t import a .tbz2, though I should mention that the plugin does tell me I have installed successfully. It is telling me fibs. ;)

So where does that leave us? The problem is still the fact that most users probably don’t use your plugin and most of those will be Windows users. Windows natively supports .zip compression/decompression. Anything else requires installing an application, my own preference being 7-zip, but how many of them are likely to install something they probably won’t use much?

Bloke · 2010-02-07 22:23:21

thebombsite wrote:

Anyway it would seem that somewhere amongst that lot certain PHP facilities I was previously denied have now been enabled.

Haha, web hosts have a habit of changing things when you least expect it. In my case, they actually downgraded my service and removed --with-zip from my version of PHP; reasons unknown. That’s what started this whole compression thing off in the first place: I had zip built into the plugin during beta testing that utilised (what I thought was) PHP’s built-in ZIP functionality. Turns out it’s an extension and midway during development the plugin stopped working on my own site. If it hadn’t been for that simple act of treason from my hoster I’d have been blissfully unaware that we’d need any other type of compression format at all!

I can’t import a .tbz2, though I should mention that the plugin does tell me I have installed successfully. It is telling me fibs. ;)

We can’t have my software lying to you. Naughty. I’ll look into it, but…

*fanfare*

I’ve just found a kind soul who has recently updated a library that purports to manage zip decompression without PHP’s zip extension. The downsides are that a) it’s 24KB so including it will take the plugin to well over 100KB in size (eeek!), and b) it still requires --with-zlib to be enabled on your server. The author of the library cheerily notes in the documentation:

Requirements:
This class requires extension ZLib Enabled. It is default
for most site hosts around the world, and for the PHP Win32 dist.

If that’s to be believed, we’re in the clear. Hosters being hosters though, it doesn’t fill me with complete confidence. Curiously, in the next paragraph of the docs we find:

To do:

Error handling

Write a PHP-Side gzinflate, to completely avoid any external extensions

Write other decompress algorithms

Ahem, so there’s no error handling built in, which is going to be fun if the zip file is somehow mangled. Could be a sticking point.

If he manages to incorporate gzinflate functionality in future, it means we’re sorted in terms of PHP requirements but it’ll boost the file size yet again. Also, if he decides to add other decompression algorithms it opens the avenue of later incorporating others again, if necessary. But, as Stuart points out, zip is arguably the defacto standard for Operating Systems (heck, even OSX from 10.3 onwards has zip decompression built in) so it makes sense to find a way to use it exclusively.

What I’ll probably end up doing is trying to consolidate what’s on offer in the plugin. If this library does what it claims on the tin I’ll add it and make the plugin use it for zip decompression. That will help in the short term. I’ll then see if I can strip out all the other encoding file formats, but for backwards compatibility I’ll quietly make v0.2 of the plugin still able to read the existing formats — it just won’t be able to create anything other than zip. After significant time has elapsed I’ll then probably remove the non-zip support entirely and see if that brings the plugin size down. Alternatively I may elect to keep it — perhaps using this new library if it’s been written — but lock it away as an ‘advanced’ feature for those that really really really have a need for something other than zip. I’d hate to lock out a bunch of potential TXP themers for the sake of 30KB of code.

Watch this space for developments.

Last edited by Bloke (2010-02-07 22:23:44)

thebombsite · 2010-02-07 23:06:05

What’s the maximum size for plugins these days? It got upped recently didn’t it?

Could it have a separate library file like Postmaster and one or two others?

And another nasty thought I just had. The Textgarden server and I also think the Textpattern server will not allow the installation of compressed plugins. If that is the case does it suggest they wouldn’t be able to import a compressed theme or is that something entirely different?

Last edited by thebombsite (2010-02-07 23:07:06)

Bloke · 2010-02-07 23:28:51

thebombsite wrote:

What’s the maximum size for plugins these days? It got upped recently didn’t it?

Yeah, 16MB¹. Got a way to go yet before I hit that ceiling :-)

Could it have a separate library file like Postmaster and one or two others?

Yes, at the expense of having to upload and activate two plugins at installation time. Swings/roundabouts I guess.

The Textgarden server and I also think the Textpattern server will not allow the installation of compressed plugins. If that is the case does it suggest they wouldn’t be able to import a compressed theme

Oooh, now you’re talking. Compressed plugins are gzipped — which implies using the gzinflate() function, which in turn is a component of ZLib and thus the server’s PHP has to be compiled --with-zlib. If both those servers can’t import compressed plugins it follows they won’t be able to install gzip compressed themes. And since the library I’m looking at requires ZLib in order to make the zip functionality work, well, it’s potentially a problem.

I’m going to have to do some heavy testing offline in XAMPP to check server configurations with and without the various libraries compiled in before I choose a route. On one hand, TAR is attractive because it only uses the pack() function which is a core component of PHP. People using smd_admin_themes will be fine; people who don’t and want to install by hand may need a non-built-in tool on their OS to read theme packages and upload them to their server manually.

On the flipside, using ZIP means pretty much anyone can read the archive on their OS natively, but only people with zlib installed can create and install them if using smd_admin_themes. Dilemma alert!

¹ In theory at least; it’ll depend on your server’s maximum upload file size and/or the maximum size of a POST request to determine whether that plugin limit is practically attainable.

Last edited by Bloke (2010-02-07 23:30:57)

Bloke · 2010-02-09 14:12:46

‘ave it! 8o)

Native zip support is built in to the (now much larger) plugin v0.2. Zip is the default export type on new installations — alter your plugin prefs if you’re upgrading.

I opted to leave all the formats intact because I found a better mechanism for kicking out unsupported types. With luck that should (untested on a live site) stop the plugin saying it’s OK to upload a bzip file when your system can’t support it, Stuart! Please report on the success or otherwise of my wranglings.

I’ve also made it a lot clearer which types your system supports via a little info line beneath the Upload box. By separating the ‘import’ and ‘export’ operations — they both use different sets of PHP functions — my checker now makes sure you have the right functions depending on which direction you’re doing things. And if you try to upload an unsupported type it’ll complain.

See how that one tickles your respective fancies.

thebombsite · 2010-02-09 14:44:41

Still something not right Stef. It tells me under the import browse field “Supported import types: Tar, GZip, Zip, BZip” but it still will not import Bzip and when I try it still reports “Installation successful”.

I maybe should mention that I can export all 4 formats no problem. Maybe I only have half a library. ;)

Bloke · 2010-02-10 09:04:45

thebombsite wrote:

will not import Bzip and when I try it still reports “Installation successful”.

Dang, must have missed a function call that it requires. Thought I’d caught them all. Thanks for the feedback, I’ll trawl the code a bit harder (and test that bit on XAMPP if I can next time!)

thebombsite · 2010-02-10 15:24:36

Well I can easily test on thebombsite. Just install a new version and away I go. As I say I can export a Bzip file no problem so I obviously have access to that side of the function, just can’t import it back again. I wonder if that is confusing the plugin.

I did a bit of a check on the exported file by unzipping it (twice because it has to go through the tar format) then re-zipping it again but in .zip format and importing that file. It imported fine and when I switched themes to use it everything was hunky-dory. This suggests to my uncomplicated mind that there was no file corruption getting in the way.

Bloke · 2010-02-10 19:31:47

thebombsite wrote:

I can export a Bzip file no problem… just can’t import it back again.

Thanks for your extra diagnostics. Good to know the bzip export is definitely working.

Just took a more detailed lookie in the plugin. I had made a small oversight insofar as I thought the import was using bzdecompress()… but that was in the new library — and I’m not actually using that part of it. So I went through the existing library and it seems it first uses bzopen() and then a standard tar decompression routine to extract the files inside. If tar works (which it does) then the only difference it seems is bzopen().

My “import” checker just tests for the existence of bzdecompress() — it should instead check for bzopen(). BUT the “export” routine checks for bzopen() and a host of other ‘bz’ functions, and not only reports success it can also export fine. Therefore I’m betting it’s actually something deeper in the bzip decompression routine that’s going sideways and not merely the existence of the required functions that’s fouling things up.

~~Please would you e-mail me a bzipped theme, and~~ EDIT: Scratch that, can you try something for me please — I can’t test it on xampp for some reason, but I have found a warning message issued by PHP. Visit line 2337 of the plugin. It should read:

return @bzopen($this->options['name'], "rb");

Change it to:

return bzopen($this->options['name'], "r");

i.e. remove the ‘at’ sign and also the binary flag, which my version of PHP is complaining about. See if that makes any difference. If it fails for some reason you shold now see an error message so we can at least see if it’s that.

I’ll see if I can find a way of setting up a local environment here that will accept them and run the bzimport routine in debug mode to track down why that particular portion fails. It might be a bug in the guy’s library (in which case I’ll either fix it or try and use the other library for decompression of bzips!) or it could be some weird permissions thing in that type of file that’s preventing extraction…. that’s a long shot though as it uses the same tar functions as gzip for decompression and that works fine on your system… very curious.

Sorry for the false start, and thanks for your continued patience while I iron this odd one out.

Last edited by Bloke (2010-02-10 20:13:09)

thebombsite · 2010-02-10 22:00:26

Still the same result Stef.

OT – but whilst I’m thinking about it, cuz you look after Plugin Composer now don’t you? It might be handy if we could have line numbers. Is that possible?

Last edited by thebombsite (2010-02-10 22:02:32)

Bloke · 2010-02-11 15:15:34

thebombsite wrote:

Still the same result Stef.

Working on it. Might not be able to look at it in more detail until after the weekend though. ‘tis a puzzler for sure.

It might be handy if we could have line numbers. Is that possible?

OT: Not really, unless you install a syntax highlighter (there are loads out there). But a poor-man’s version of a line number assistant has popped in for a chat

thebombsite · 2010-02-12 19:37:44

Bloke wrote:

OT: Not really, unless you install a syntax highlighter (there are loads out there). But a poor-man’s version of a line number assistant has popped in for a chat

That works nicely thanks. Now you can throw line numbers at me all day. ;)

Textpattern CMS

Textpattern CMS support forum

#85 2010-02-07 15:35:30

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#86 2010-02-07 22:23:21

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#87 2010-02-07 23:06:05

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#88 2010-02-07 23:28:51

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#89 2010-02-09 14:12:46

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#90 2010-02-09 14:44:41

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#91 2010-02-10 09:04:45

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#92 2010-02-10 15:24:36

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#93 2010-02-10 19:31:47

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#94 2010-02-10 22:00:26

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#95 2010-02-11 15:15:34

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

#96 2010-02-12 19:37:44

Re: smd_admin_themes: Manage, edit, switch and share admin-side themes

Board footer