Adriano Faria Posted November 6, 2015 Posted November 6, 2015 Honestly, I don't see any sense in doing this. You require us to inform a file name when creating a hook and when you install it, it goes away: I have nothing else to do but enter in each of those files to find the one I want to edit! You already stopped renaming the plugin folder, that's a HUGE step forward. Now please, stop renaming file names too. EDIT: other situation: sometimes we need to support a client and very often make some quick change in a hook while we don't release a new version. How to do that ? I don't know which file to edit!
CodingJungle Posted November 6, 2015 Posted November 6, 2015 this is one of the reasons why i don't do "plugins" for custom work anymore. lately i've just been creating applications, even if i don't need the "full" application abilities, just cause its a pain the butt to try to keep it in a "dev" environment if i ever need to do any work on it in the future. i use to have a script that would take a plugin and convert it back into a dev build, but it stopped working and just haven't gotten around to figure out why.
Makoto Posted November 6, 2015 Posted November 6, 2015 For my dev scripts, I just utilize a bit of a hackish way of re-importing the development resources on plugin installation. You can take a look at my Query Toolbox plugin on GitHub to get a general overview of how I do it,https://github.com/FujiMakoto/IPS-Query-Toolbox/blob/master/dev/setup/install.php It's basically just base64ing a tarball that contains your development resources (or any other libraries your plugin may need) and then extracting them on setup. It's a bit tedious to maintain, so I plan on writing a utility of some sort to do automate before building the plugin. I could post it here whenever I do get around to writing it if it'd be useful to you.
CodingJungle Posted November 6, 2015 Posted November 6, 2015 Thanks, you can release to others if you like. I'll just continue to make applications. In most systems out there, there is no real distinction between "plugins" and "applications". Plus an application allows me to easily write my own class files to call upon, where a plugin, not so much :). maybe with 4.2 they could make it where there isn't that "divide".
Kevin Carwile Posted November 7, 2015 Posted November 7, 2015 There are a ton of marketplace items that are really just more or less "tweaks". I believe the idea was that those could stay out of the application namespace by being "plugins". Its an interesting problem. With thousands of plugins that share class namespaces, there is going to undoubtedly be conflicts. Its already a possibility with apps. There should probably be a master registry that tracks namespaces and their availability. The marketplace would also be much more friendly if there was clear seperation between the apps which offer unique new feature sets, and plugins that tweak existing features.
Makoto Posted November 7, 2015 Posted November 7, 2015 I think the plugin system could definitely use a bit of overhaul in 4.2. I use the above method to get around some of the plugin limitations in my other plugins. For example, out of the box, it's not possible to easily include any third party libraries with plugins. I don't think you should need to create an app just to be able to utilize third party libraries, when the end result is just to use that third party library to make some small tweaks to an existing plugin or application. That, in my mind, is what separates plugins and applications anyways. Plugins are designed to alter the behavior of existing applications. Applications.. well, introduce something entirely new into the software suite. They don't exist just to modify other existing applications. I really hate having to create applications just to do that, which is why I've gone a bit above and beyond to avoid it in a couple situations.
Kevin Carwile Posted November 7, 2015 Posted November 7, 2015 37 minutes ago, Makoto said: I don't think you should need to create an app just to be able to utilize third party libraries, when the end result is just to use that third party library to make some small tweaks to an existing plugin or application. I recognized this problem back before IPS4 even released. Thats why I built the libraries app with the idea that it could serve as a common repository to include 3rd party libraries to be shared between apps and plugins. Seemed like a good idea. Thats how it gets done in other frameworks like Drupal. Sadly, the culture around here is for everyone to stay in their own corners.
Makoto Posted November 7, 2015 Posted November 7, 2015 Just now, Kevin Carwile said: Sadly, the culture around here is for everyone to stay in their own corners. But I like my corner. It's nice and cozy over here. In all seriousness though, I think the main problem is that approach suffers from a major inherent flaw, which is that it requires people install multiple other third party plugins or applications in addition to your own application or plugin. It's less of a problem when licensing allows for free distribution of the third party resources, but it's still not really ideal. To be fair though, I haven't seriously reviewed your libraries application yet, I should look it over sometime. I've been wanting to see how feasible it is to develop a system where third party resources can be packaged into other applications and plugins directly, so that they are installed automatically (and upgraded if the users already has an older version of the library installed), but I'm not really sure how feasible that is going to be. This is also why I think a repository system would be a great idea. A repository would make it incredibly easy to list application / plugin dependencies.
CodingJungle Posted November 7, 2015 Posted November 7, 2015 well look how it is done in wordpress or xenforo. you create the "apps" / "plugins" using the same system, and you are able to make it as simple as a quick theme hook to a full blown application. sure you are going to run the risk of having namespacing conflicts, regardless of how you go. It is one of the reasons i try to append "cj" to everything i do, its less likely to have that conflict when it comes to simple names
Management Lindy Posted November 7, 2015 Management Posted November 7, 2015 I'll bring this up for development. Please allow some time for a reply.
Stuart Silvester Posted November 12, 2015 Posted November 12, 2015 Plugins exported from 4.1.4 or newer AND installed on 4.1.4 or newer will now retain their original filenames when installed.
Stuart Silvester Posted November 12, 2015 Posted November 12, 2015 Just to clarify, when installing a plugin that was exported on an earlier version it will fall back to use the randomised name. In reverse installing a 4.1.4 plugin on 4.1.3 or earlier will also use a randomised name.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.