-
-
Notifications
You must be signed in to change notification settings - Fork 412
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
Add wordpress-core type #77
Comments
@sham I have read the Drupal ticket before opening this one, however I don't know their specifics enough to follow. To be clear I am not asking for the files-in-root case here, just to make handling WP core a little more robust with better default case. There are no autoload issues or anything because WordPress core doesn't use autoload. FuelPHP ticket seems to imply that "core" packages would need additional testing, however in WordPress case I don't see difference between already working plugin/theme types and potential core type. |
I'm also reluctant because it seems create-project exists to handle this use case. |
You mean using WP core as root package? But then you need to edit it and essentially cannot update it... Anyway I see your concerns about core types from the installers side. Since WP as project is nowhere near using Composer officially, I guess dirty hacks will have to do for private use for developers meanwhile. :) |
@slbmeh saw that, hadn't tested yet (as above we don't need this to make it work, just need to mess with path customization). It just seems like really tiny code change for WP installer, but drags too many considerations with it as above. |
WP extensions are already finely supported by installers, but the situation with WP core itself is less smooth. If it is placed in root then it's not subject to Composer, however subdirectory installs (which only recently became supported for all cases) are and probably should be.
However typical subdirectory install for WP is not the same thing as for typical Composer library, because paths matter, are exposed in admin area URLs, etc. In a nutshell putting WordPress core into vendor directory would be atypical and possibly problematic (technically and/or to satisfy requirements of specific projects).
Currently working options:
wordpress-plugin
installer type and customize installer path for it towordpress
(or other desirable path with single level of nesting). Confusingly puts core into plugins directory, if path is not customized.wordpress-core
type. More logically goes intovendor
if path is not customized, but non-existent type feels like a hack, I am not sure won't stop working.Proposal:
Add
wordpress-core
type with defaultwordpress
path for valid subdirectory install by default without path customization.The text was updated successfully, but these errors were encountered: