Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Plugin too large - any remedy?
Hi,
I seem to have run into some kind of maximum plugin size limit. My recent plugin is approx. 106KB large, and I’m able to upload it without problems. Textpattern also shows the plugin correctly in the preview. However, if I then click “edit” on the plugin screen, I see that the source code got cut off somewhere near the end (approx. 250 lines missing). Textpattern also throws an error if I activate the plugin and move on to another screen, even though the code itself is correct (works nicely if placed in the plugin directory for development).
Question is: Has somebody already experienced this problem? Is there a workaround (except for trying to downsize the code, which would mean throwing away all comments, etc.)? This problem also exists in 4.0.4.
Any help is greatly appreciated. Thanks!
Last edited by nighthawk (2007-01-01 22:09:21)
Offline
Re: Plugin too large - any remedy?
The help and code part of the plugin are each limited to 2^16 or 65536 bytes (64 kiB) due to the column type (TEXT) used in the txp_plugin table. Textpattern itself doesn’t check these limits, so MySQL truncates anything larger than the column limit. That’s why you don’t get errors during uploading and preview.
If you only use this plugin privately, you can try changing the column type for the code (and code_restore) columns in the txp_plugin table to MEDIUMTEXT instead of TEXT. That gives you 16MiB room.
Other solutions might be:- writing more efficient plugin code (by making use of TXP internal functions, avoiding duplicate code)
- splitting part of the code into a separate plugin (type 2, library)
Last edited by ruud (2007-01-02 00:24:08)
Offline
Re: Plugin too large - any remedy?
@ruud
Thanks for your help! This explains a lot… I already tried to split it into two plugins, but it didn’t work – obviously because you can’t use two type 0/1 plugins and share functionality between them. Could you point me somewhere where I can find some more details on this type 2, please? This certainly is the best solution for the problem.
Regarding more efficient code… there certainly is room for improvement, but I’m already using lots of TXP functions. As I’m programming something TXP isn’t capable of doing yet (image gallery management), there’s lots of new functionality to be added. Yet, I do know that my code is crappy in places. ;)
Thanks again!
Offline
#4 2007-01-02 03:00:41
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Plugin too large - any remedy?
obviously because you can’t use two type 0/1 plugins and share functionality between them
Sure you can. grep ‘include_plugin’.
Alex
Offline
Re: Plugin too large - any remedy?
@zem
Okay – meaning, if I create a type 2 plugin, I can include it as a library by calling include_plugin and then access its functions? Will try that later today – thanks!
Last edited by nighthawk (2007-01-02 10:36:18)
Offline
Re: Plugin too large - any remedy?
Many thanks guys, works perfectly! If you want to see the results, see the thread for the wow_gallery plugin (will be uploading the latest version in one or two hours).
Offline
Re: Plugin too large - any remedy?
hmmm – interested in the best way considered to achieve this… Front-end v Back-end is an obvious one I guess…
BE + MEngSc = engineer with a side dish of frustrated designer/developer with a penchant for photography outside
Offline
Re: Plugin too large - any remedy?
Apart from the options mentioned above, there is another way I think it can be done…. compression!
Suppose you store the plugin code like this: $compressed_code = base64_encode(gzdeflate($code));
Upon loading the code, you could probably do eval(base64_decode(gzinflate($compressed_code))); or something like that.
Or let the initial plugin contain two parts: a part that changes the column type of the txp_plugins table to allow bigger plugins and a part that contains a compressed plugin that will replace the initial plugin when the txp_plugins table no longer has the 64kB restriction. The advantage of that approach is that decompression is no longer needed each time the plugin is loaded… although I suspect decompression is not very CPU intensive and may balance out the having to load a larger part of code from the database.
Offline
Re: Plugin too large - any remedy?
I really think the best way is to split the plugin. Front end/back end separation is probably the most reasonable way as you won’t have to guess where to look for certain functions. :) I moved all the backend/helper functions to a library plugin and placed the rest in the frontend part. Thanks to ruud’s and Zem’s hints, it works flawlessly.
@jufemaiz: looking forward to the next version of jmc_event_manager. :)
@zem: Any way of making this a sticky topic? I guess it’ll be interesting to know for other developers as well how to handle larger plugins.
Last edited by nighthawk (2007-01-21 14:57:16)
Offline
Re: Plugin too large - any remedy?
@nighthawk: can you give a quick “how to” on how you disentangeled things?
BE + MEngSc = engineer with a side dish of frustrated designer/developer with a penchant for photography outside
Offline
Re: Plugin too large - any remedy?
@jufemaiz
I mainly separated txp tag functionality from the rest, but aside of that, I didn’t follow any strict separation rule. You can use the wow_menu plugin as an example, that’s the one where I had the size problem and solved it by the solution depicted above.
Give it a try – if I can get it done, so can you. :)
Offline
#12 2007-02-26 01:51:14
- nickadeemus2002
- New Member
- Registered: 2007-02-26
- Posts: 4
Re: Plugin too large - any remedy?
hi. i’m really interested in textpattern plugin development. if the php source file is too large, is it against textpattern’s code standards to create an includes directory on the remote server and use ‘include’/‘require’ statements in the plugin-code to reference them?
Offline