Released 29. Jan 2011 http://community.mybb.com/thread-87399.html
Hi,
PluginLibrary is a collection of useful functions used by other plugins. Or, at least, that's the general idea. I'm sure there are better words to describe it but those will have to wait until later.
I'll use this in future versions of my plugin(s) and I'm releasing it as public BETA now, so eventually, others can use it too.
Please don't actually use it in production as long as it's in BETA. Instead, please test it and/or give me some comments and/or other constructive input. Thanks!
The current features are:
- Setting groups and settings. Create, update, delete. Generate settings language file. No more SQL-fu, just a single function call per setting group, with settings passed as array.
- Delete caches. MyBB can create them but offers no obvious way to clean up.
- Edit core files. Make / update edits to PHP/JS/CSS files, using search patterns, insert before/after and/or replace. Undo edits. Some limited ability to detect conflicts with edits by other plugins.
I expect the list of features to grow over time.
There's no documentation yet, but a demo plugin that demonstrates the features. See inc/plugins/hello_pl.php in the archive. I'll try tob write more elaborate documentation once I'm sure I won't change things around too much.
Comments, opinions, flames, ...?
Regards
frostschutz
GitHub:
https://github.com/frostschutz/PluginLibrary
This is something I've been thinking to do for sometime now. Can we contribute? There's an issue I've thought about as well. What about plugins that come with a newer version of the library and the user has a plugin which already uses the library, but an older version?
(2010-12-17, 09:43 PM)Pirata Nervo Wrote: [ -> ]Can we contribute?
Yes! Contributions are welcome as long as they are useful to plugins in general and not too extensive; so if you have any useful gems or snippets which you've been using in your plugins, and would like to share, please let me know about it and we'll figure something out.
(2010-12-17, 09:43 PM)Pirata Nervo Wrote: [ -> ]What about plugins that come with a newer version of the library and the user has a plugin which already uses the library, but an older version?
The current plan is like this:
The library itself is a plugin. It's listed on the plugins page, and shows the version number (which for simplicity reasons will be just a number, not 1.2.3.4). If there are updates for the library it will also show in the plugin updates tab. So users can manage it like they manage any other plugin, there's nothing special about it.
You don't ship the library with your own plugin. Instead you check if it's there and at least the required version, and if not you present a hey please install this other plugin too download link on the plugins page. The demo plugin already does these dependency and version checks. The download link currently points to the GitHub page, in the final version this will of course go instead to the MyBB Mods Database.
The library itself will naturally have to be backwards compatible, so newer versions of the library won't screw up plugins made for older versions. I sincerely hope there won't be any hiccups that requires plugins to be updated; Currently the edit core feature is the most risky one in terms of backwards compatibility; it's the only feature that's "new" and thus not nearly as well tested as the others.
Also the main reason for this to be BETA right now. I'll declare it stable once I'm actually using it in my own plugins (sometime January), and until then I may still change around some things.
Alright, I'll start using it in my own plugins as well. How do I get my functions submitted? Should I post them here?
We can discuss feature ideas here, or by PM or E-Mail. If you already have code, you can post it or attach it. There's also an issue tracker and wiki available at GitHub. And then of course, there's git itself. Discussing here is probably easiest though.
Please don't write a lot of code for this project without discussing the idea first. I will refuse to include a feature if I'm not convinced of the necessity and/or usefulness of the feature for plugin developers in general; I will also refuse if it's poorly implemented. Also, I decided to make this project LGPL. That's the same license as MyBB so everyone who uses MyBB should also be able to use this. For submissions that means they have to be made under the same license.
I have a question though:
$result = $PL->edit_core("hello_pl", "inc/plugins/hello_pl.php");
How does this removes our inserted code and puts back the old one? I haven't tested it, but I plan to do it tonight. I guess I'll find out by then haha
The edit_core feature works by locating a range of lines in a file that should be changed (you specify that range using search patterns, I will have to write a documentation on how those work exactly); and then inserting code before or after those lines.
After the edit, the changed lines of code all start with a comment:
/* + PL:pluginname + */ inserted_before();
/* - PL:pluginname - /* original_removed_commented_code();
/* + PL:pluginname + */ inserted_after();
This is what makes most additional features of edit_core possible: It checks whether edits collide with edits made by other plugins, by checking whether there already is a /* +- PL: comment in the area you want to modify; it can undo changes by removing the inserted, and uncommenting the removed lines; it can update changes by undoing first and then reapplying the (possibly changed) edits.
However it also means there are some limitations: You can only edit files that use /* */ comment style (so it's good for PHP/CSS/JS but not for plain text, plain html or .htaccess); also there could be problems if the code you want to change has /* */ comments. However I haven't found an occurence in the MyBB codebase where this would be a problem.
The purpose of this feature is to handle simple edits, things that plugins sometimes need to do, like inserting a hook somewhere when there isn't one you can use, or replacing a function call, stuff like that. It's not meant for complex edits where you replace half the codebase. That's something better left to more powerful tools like diff/patch.
Oh, nice idea! I'll look deeply into it today and tomorrow and may post a function to be submitted if you accept.
why make this a "plugin" when its not run like a plugin? There are no settings, no activate/deactivate, etc. Why not just make it "class_pluginlib.php" and stick it in \inc folder?
that way you can extend the existing PluginSystem class by adding your functionality so we can use one class variable to use both builtin and your code together?
(2010-12-18, 06:04 PM)pavemen Wrote: [ -> ]why make this a "plugin" when its not run like a plugin?
Explained that above:
(2010-12-17, 10:42 PM)frostschutz Wrote: [ -> ]It's listed on the plugins page, and shows the version number (which for simplicity reasons will be just a number, not 1.2.3.4). If there are updates for the library it will also show in the plugin updates tab. So users can manage it like they manage any other plugin, there's nothing special about it.
Making it a plugin makes a lot of sense since it's directly - exclusively - plugin related. Users know how to install, uninstall, and update plugins, so they're more likely to be able to handle it this way, rather than having an invisible file somewhere. It's also a way of notifying users of problems and bugs in the library as they're more likely to notice new versions along with plugin updates, something they wouldn't do for some other file.
In short, it's the solution that is most end user friendly.
(2010-12-18, 06:04 PM)pavemen Wrote: [ -> ]that way you can extend the existing PluginSystem class by adding your functionality so we can use one class variable to use both builtin and your code together?
If I wanted to do that, I could, regardless of where the file is placed. I don't want to do that, for many reasons. The main reason being that I want to make it obvious in the plugin source code, that this is not a MyBB core feature being used there. I don't want people in forums posting code like $plugins->settings() and then other plugin authors getting confused by that because usually there is no such function. I also want to avoid namespace collisions with the $plugins class. It's just not good style to mess with the original MyBB classes and besides, I don't see any advantage in it.
In general, classes in MyBB are classes more for clarity of syntax reasons, not so much for OOP and code reusage / inheritance reasons. Compare db_mysql.php and db_mysqli.php and you know how much code reusage is done within MyBB - none. Classes are for OOP, but just because you're using classes does not make it OOP.