Package builder seems to have gone off the rails (at least my copy).
After a lot of failed attempts to build and install really simple packages, I went back and tried to build the EzFAQ snippet again using the exact same code I used originally. The earlier transport package I created for the snippet still installs fine on a new install of Revolution. Using that code again causes this error:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 6363520 bytes) in C:\xampp\htdocs\MODx097\core\model\modx\modscript.class.php on line 55
The size of the transport package at the time of the crash is 1.19 Megabytes (as opposed to 18.75 kb for the one I created earlier). The folder created for the build is 1.45 Megabytes (as opposed to 38K for the older one).
It appears that the builder code is trying to build a package that includes the entire site. The results are the same whether I use the Package Builder GUI in the Manager or the builder snippet code I created earlier.
Even if the build only creates one system setting, there are folders for snippets, plugins, systemsettings, etc. and all the systems setting keys in the source install appear in the new site after the Package install (even though the install fails -- probably when it runs out of memory).
From the debug info produced during the build, it looks like it’s building in all system settings and all lexicon entries. It runs out of memory before it gets beyond those.
This is actually expected - and maybe needs discussion.
Currently the Package Builder now auto-includes all Settings (system and context) and Lexicon Entries (which is now how Lexicon strings are loaded - from the DB, and cached in a file). It finds which ones to load by loading them via ’namespace’; which you can create.
Now currently if you select the ’core’ namespace, it will auto-find all the settings/lexicon entries that are of the ’core’ namespace. This is something we probably should change and make an exception for.
Generally, however, you should not make packages with the ’core’ namespace. Maybe we should prevent that namespace from being shown? You should create a namespace based on your package.
shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect |
github |
splittingred.com
-
MODX Staff
- 10,725 Posts
+1 for excluding the core namespace from the interface.
Actually, I tried to use my own namespace, but in IE7, there doesn’t seem to be any way to do it -- it’s a dropdown list and ’core’ is the only choice. In FF, the namespace field doesn’t appear and ’core’ is the default for the namespace argument so I can’t see any way out at this point.
function create($name, $version, $release= '', $namespace = 'core') {
+1 with Jason.
I got a little closer, but no cigar. I figured out how to create the new namespace (doh!). Then I went into PhpMyAdmin and, in the system_settings table, set the ’namespace’ field to the new namespace for my three system settings.
The Package Builder GUI is a little better behaved and it does automatically transfer the system settings without my specifying them. I can move the plugins, but I still can’t get any of the resolvers to work although the error log suggests that there’s a problem with the namespace so I’m guessing I have to delete my three system settings and re-create them with the new namespace specified.
If somebody can give me a full package builder script (preferably one that runs outside of MODx -- although I’ll take anything at this point) that includes resolvers, pulling existing objects from the DB and handles system settings, I’d prefer to do it that way anyway.
All I have now are various pieces of code from different points in the development process and, so far, I haven’t been able to get them to work together.
Quote from: splittingred at Aug 18, 2008, 11:30 AM
BobRay,
I’ve just committed a new Package Builder that includes a panel where you can select which classes get pre-packaged in.
You’ll definitely need to recreate your system settings with the correct namespace. A GUI needs to be created for system settings allowing you to change the namespace for them without having to recreate.
I’ll test resolvers later today. More coming, I promise. 
Cool. I’m testing it. BTW, newly created yes/no system setting key values can’t be edited in IE7 or FF. You can change the values of existing ones and text ones, but any new yes/no ones seem to be locked (double-click has no effect).
Quote from: splittingred at Aug 18, 2008, 01:45 PM
Quote from: BobRay at Aug 18, 2008, 01:37 PM
Cool. I’m testing it. BTW, newly created yes/no system setting key values can’t be edited in IE7 or FF. You can change the values of existing ones and text ones, but any new yes/no ones seem to be locked (double-click has no effect).
Fixed issue. Committed in r3941.
Still not working for me. I can edit the name but not the value of yes/no settings.
