Conversation
Current implementation looked in a directory at the same level as the base plugin class (typically `src/config/` (This is unrelated to the other *resources* path changes; just tidying up!)
… use when registering scripts + styles.
Vite still has its own URL generating scheme…? 🤷
This makes it easier to generate URLs to publishable assets:
```php
public function register(HtmlStack $htmlStack): void
{
$path = Plugin::getInstance()->getPublishablePath('js/editFs.js');
$htmlStack->jsFile(asset($path));
}
```
If it's not too ambiguous, we could make an additional helper akin to `craftAsset()`… say:
```
pluginAsset('handle', 'js/editFs.js');
// -> https://my-project.ddev.site/vendor/craftcms/aws-s3/js/editFs.js
```
|
Seems good to me, we’ll have to make sure the structure of existing plugins still works to make it easier on devs porting their plugins |
|
@AugustMiller can you review the failing checks? |
|
We’re already requiring that templates be moved into a Plugin config files have historically only provided as stubs for developers to copy into their local project, not for plugins to interact with… and while this is technically not "compatible" with that convention, discovery + publishing of config files is a new feature in 6.x. The only additional "breaking" change ends up being that (Re: checks—sorry for all the noise. I will spend some time next week getting them to run locally.) |
|
I don't think I can get the failing test to pass, because it's only doing a string comparison. Is it appropriate to use |
3 participants
Proposing a slight re-restructuring of the recommended plugin package…
config/is now a top-level directory;resources/is now a top-level directory, and this is standardized by a newPlugin::getResourcesPath()method;resources/location;InteractsWithCp) are now expected to be in theresources/directory (not floating, adjacent to the base plugin class);HasFrontendAssets::getPublishablePath()method consolidates a number of instances in which we were building paths in thepublic/vendor/dir;The main issue I see here is that if a plugin’s base class is at the top level of its package (not in a
src/directory), we'll be traversing above its root while looking for config and resources. (This is a preexisting assumption that we make elsewhere in the plugin architecture!) If a plugin has this structure, it should overridegetResourcesPath().