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

Add wordpress-core type #77

Closed
Rarst opened this issue May 24, 2013 · 6 comments
Closed

Add wordpress-core type #77

Rarst opened this issue May 24, 2013 · 6 comments

Comments

@Rarst
Copy link

Rarst commented May 24, 2013

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:

  1. Declare core to be of wordpress-plugin installer type and customize installer path for it to wordpress (or other desirable path with single level of nesting). Confusingly puts core into plugins directory, if path is not customized.
  2. Declare core to be of fake wordpress-core type. More logically goes into vendor 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 default wordpress path for valid subdirectory install by default without path customization.

@shama
Copy link
Contributor

shama commented May 24, 2013

Please see #38 and #57

@Rarst
Copy link
Author

Rarst commented May 24, 2013

@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.

@shama
Copy link
Contributor

shama commented May 24, 2013

core types would exist for only 1 package where other types exist for many packages. I understand core types seem really useful but they seem problematic to me. As soon as 2 packages use the same core type it is going to blow up. I'm not saying no to core types I'm simply asking if someone really wants them and for me to maintain them... then please include actual package install tests: #43

I'm also reluctant because it seems create-project exists to handle this use case.

@Rarst
Copy link
Author

Rarst commented May 24, 2013

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. :)

@Rarst Rarst closed this as completed May 24, 2013
@sbuzonas
Copy link

sbuzonas commented Jun 4, 2013

@Rarst in PR #53 I opted to create a separate installer because it didn't seem to fit the purpose of this project IMO.

@Rarst
Copy link
Author

Rarst commented Jun 4, 2013

@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.

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

No branches or pull requests

3 participants