Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for new table: modx_extension_packages #25

Open
fireproofsocks opened this issue Nov 16, 2014 · 8 comments
Open

Support for new table: modx_extension_packages #25

fireproofsocks opened this issue Nov 16, 2014 · 8 comments
Labels

Comments

@fireproofsocks
Copy link
Member

When did this table get added? How does it interface with the existing System Setting? WTF?

@pk-informatics
Copy link

as far as i know gallery adds it during installation (http://rtfm.modx.com/extras/revo/gallery), searching the whole install zip doesn't show up any match for extension_packages...

@pk-informatics
Copy link

but on my current project the settings doesn't exist, the quick'n'dirty way would be to add it over the seed only if it is not existing

@pk-informatics
Copy link

and the script has to resolve [[++mypkg.core_path]], on my installation it has only worked with the full path without the system setting

@pk-informatics
Copy link

Regarding to http://rtfm.modx.com/revolution/2.x/administering-your-site/settings/system-settings/extension_packages i think it will be easier to use the two functions addExtensionPackage and removeExtensionPackage to provide the same function, i don't see any benefit from using the table? and on my installations it is empty...

@fireproofsocks
Copy link
Member Author

This was more of an internal note and I didn't expect a thread to be started here. The table was added by MODX at some point and it continues a frustrating trend on their part for adding undocumented (and sometimes ill-conceived) architecture. The system setting is kinda a twerky way to do it, so I can see the table being more fruitful, but I don't see it actually being used either. Argh.

I'm confused by your comments here (and they probably belong in a separate location). Repoman creates a series of system settings including one for the [[++mypkg.core_path]] -- that resolves to the custom location where you are developing your package and using version control. If the package is installed WITHOUT repoman (i.e. as a transport package), that system setting will be blank, so as long as you have followed the coding conventions (see https://github.com/craftsmancoding/repoman/wiki/Conventions) re the core_path, then MODX will know where to find your code. I feel like there must a few things fundamentally off with your work-flow if you're running into things like this...

@pk-informatics
Copy link

at the moment i am working with my first repoman package :) so it could be definitely a bug in my workflow - does it work with your packages if you try to use [{"mypkg":{"path":"[[++mypkg.core_path]]model/"}}] for the system setting?

@fireproofsocks
Copy link
Member Author

No, I don't think that will work because the logic that parses those strings in the extension packages System Setting isn't actually the MODX parser. Instead, you need to create a model/migrations/install.php file and use addPackage there. Repoman will handle it from there. See moxycart as an example: https://github.com/craftsmancoding/moxycart/blob/master/model/migrations/install.php

Also Taxonomies: https://github.com/craftsmancoding/taxonomies/blob/master/model/migrations/install.php

I haven't added docs for the migrations yet...

@pk-informatics
Copy link

Aaaa okay, thank you for the info, then i could fix my code yet :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants