Any chance of desuckifying the plugin development experience

[Colonel_mortis]

I want to check my code into git, and be able to get started on a new install fairly easily by just cloning it. This lends itself well to collaborative environments, being able to easily recover from scrapping and restarting development environment, and potentially even CI workflows. I also currently deploy my code using git.

For apps, it's great. I just clone my repo, click an install button in ACP, and I'm good to go. For plugins though, it really sucks:

• Hook information isn't stored in a file anywhere, so in order to check in enough information to reinstall the plugin I would need to download the xml, copy it back to my plugin dir, then commit that too
  • Then I get those annoying uncaught exception handler blocks added in my dev environment
• For that reason, plugins can only be installed through the "upload xml" workflow, so installing a dev version means installing the xml then finding it in disk and adding the dev files separately
• Hook class names are install-specific, so once I get it installed in a new environment I end up with a bunch of git changes - this makes it impossible to collaborate with them
• Plugin names are case insensitive and get lower-cased when xmled, which looks ugly when you've installed a camel-cased plugin. There's also no option to make them snake- or kebab-cased because of the arbitrary alphanumeric restriction

For these reasons I've been trying to centralise my plugins into apps, but that loses the flexibility of having small plugins that just do what they say on the tin, without needing to worry about a place for a settings UI for one or two options. That solution is obviously untenable for plugins that aren't just being developed for a single site though. If you implemented these fairly simple changes (hooks.json file, install from disk, custom names for hook classes, retain case and allow -_ in plugin names), I would be much happier when developing small changes like this.

I think all of these things can be implemented in a backwards-compatible way (for hooks.json, if not present fall back to creating it based on the contents of the DB), so I can dream that my complaints haven't missed the 4.5 boat.

Edited June 25, 2020 by Colonel_mortis

[Stuart Silvester]

4.5 contains a bunch of improvements in this area to make plugins more portable. They can be installed IN_DEV and the majority of their data is now stored within the /dev directory in various PHP/JSON/PHTML files.

We haven't made any changes to the naming conventions required, or the hook class names, but we've also come up with these changes for the same reasons, to greatly improve the ability to develop plugins across installs via Git.

Please consider taking a look at the beta and letting us know whether those improvements are beneficial to your development process.

[The Old Man]

Thanks for this. As a noobie, I was surprised how much is done outside of the dev center and in a text editor or IDE when creating a plug-in.
I was kind of expecting to see live variables, strings in a sidebar, with realtime error messages or something. Something called Whoops appears sometimes, but its a bit overwhelming and there is nothing to say how to use it in the tutorials section.

Its taken me 3 days to work out how to make a quick debug entry and I still can't get it to log the form->$values I've just saved inside it. Why is an exception with a 200 message needed when 1 line of text would surely do? I'm obviously a newbie.

[Colonel_mortis]

On 6/25/2020 at 9:58 PM, Stuart Silvester said:

They can be installed IN_DEV

I may have misunderstood what you mean by this, but I can't seem to find any way to install a plugin from the files without the XML, IN_DEV or not.

Writing the hook data to disk is great though, and if nothing else the XML file can at least now be reconstructed.