For those installing via starter-project/Elgg as a dependency
By Steve Clay
When Elgg is installed in the /vendor directory (if installing via composer or from .zip), one can add a start.php file and a views/ directory at the site root and these (sort of) behave like a plugin.
They don't constitute a real plugin, can't have settings, the start.php can't be disabled and is called before all other plugins (yet the views/ are pulled in last).
I think this non-plugin concept is confusing and users would be better off learning how to make real plugins from the start. Also the code to implement this behavior is hacky since it must lay outside our other plugin code.
Who is using this, and does anyone think it's an essential feature?
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 0 likes
- Make changes to a plugin
- Commit changes to plugin git repo
- Pull in the new plugin version with composer
- Commit the updated composer.lock to project repo
- Make changes
- Commit to git repo, done!
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 1 like
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Juho Jaakkola@juho.jaakkola
Juho Jaakkola - 0 likes
You must log in to post replies.I'm not using it and I think it's extra cruft that we don't need to support. Make real plugins.
I've been using it extensively. I like it how I can make quick changes on the fly.
Plugin workflow (slow):
Installation root workflow (fast):
I guess an alternative approach for quick and easy changes could be to explicitly unignore a single plugin under mod/ to make it work as if it were integral part of the project.
Yeah, keeping site-specific plugins in the repo is handy.
Would it be beneficial to bless some plugins as "essential" so they can't be disabled, and must be ordered last?
I like that idea. We could have a plugin_id unignored by default. Perhaps even have a plugin skeleton under mod/ for it by default.