composer: type of "wordpress-plugin" about extended-cpts

[johnbillion]

Thanks Chris, do you think I should remove this line altogether?

Previously: #6. /cc @spacedmonkey

[ctalkington]

i guess i see that this library can also be loaded as a plugin based on the headers its carrying. thats kind of confusing seeing as its not published to the repo or such currently.

EDIT: it also seems like more of a developer library which it even calls itself in multiple places.

[johnbillion]

Yeah it has the plugin header mostly for ease of use. It's primarily intended as a library that should be included as a dependency in a project, but it can also be activated as a plugin.

I guess I could make a breaking change and remove the plugin header and the wordpress-plugin type from composer.json.

[ctalkington]

thought as much, to me it seems best to adjust for the primary intended users (ie library) unless it will drastically hurt your ability to test and enhance this otherwise great library.

[jjeaton]

FWIW, I ran into this earlier as I am using this as a library within an existing plugin and was able to solve it by doing this:

"require": {
    "johnbillion/extended-cpts": "2.4.*"
},
"extra": {
    "installer-paths": {
        "vendor/{$name}": ["johnbillion/extended-cpts"]
    }
}

Since I'm using this as a dependency for a plugin This places the library in my-plugin-dir/vendor/extended-cpts, although you can change vendor/{$name} to be wherever you want.

I found this here: https://getcomposer.org/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md

This should give you the flexibility you need to put it wherever you need in your project.

Aside: Something that would be really nice is a way to say "only give the plugin files" without the tests and everything else, for when you're deploying. I instead have all the extra files deleted in a build step prior to deployment. Hope this helps.

[ctalkington]

@jjeaton thanks for the tip. i knew there was some way to override but had last track of that page.

definitely remedies the issue in the short term.

EDIT: also you can do vendor/{$vendor}/{$name} which mimics the usual generated paths.

[johnbillion]

Version 3.0.0 of Extended CPTs no longer has a plugin header or a type entry in composer.json.

[aaemnnosttv]

@johnbillion by removing the type header, it also breaks the ability to override the install path.

Note: You cannot use this to change the path of any package. This is only applicable to packages that require composer/installers and use a custom type that it handles.

source