cotonti.com : Plugin API changes https://www.cotonti.com Last topic posts Cotonti en Tue, 14 Apr 2026 19:48:51 -0000 GHengeveld
Recently I've been working with AJAX plugins a LOT (custom implementation for a customer). I've already done some modification in the plug module to allow POST requests more easily.]]> Mon, 03 May 2010 18:15:55 -0000 Trustmaster Thu, 11 Jun 2009 13:07:08 -0000 Xerora 
<?xml version="1.0" encoding="UTF-8" ?>
<setup version="1.0">

	<information>
                <type>module</type>
		<code>gallery</code>
		<name>Gallery</name>
	</information>
	
	<hooks>
		<hook location="standalone" file="photos" order="1" />
                <hook location="main.first" file="loader" order="2" />
	</hooks>
	
</setup>
]]> Thu, 11 Jun 2009 09:18:27 -0000 Dayver Major upgrade (or Brand new but very carefully) ? I hope so!

# Trustmaster : OK, here is a list of suggestions I have collected so far:
[list=1]
  • Remove SED_EXTPLUGIN block from every single plugin file...
  • Specify hook bindings as an array in setup file like:
    $hooks = array(
	array('filename1', 'hook1', 10),
	array('filename1', 'hook2'),
	array('filename2', 'hook3', 99)
);
    where the third optional parameter is priority (order). As you can see, it also allows for multiple hook bindings.
  • Automatically preload plugin permissions into $usr['auth_read'], $usr['auth_write'] and $usr['isadmin'].
  • Automatically preload plugin langfile.
  • Already added in tickets: simplify CODE check. It can be
    defined('COT_CODE') or die('Wrong URL');
  • Time to change sed_ to cot_

    • More brainstorming while writing a plugin:

    7. Auth hooks. Add ability to affect auth in exact places (already known as EYOOP issue).

    8. SQL query hooks. There are some important queries that a plugin developer would like to modify before they get executed...


    I known that all the items we must to do because all these improvements will reduce the time to create new plugins! And we must do so now because the little time.


    # Trustmaster :
    UPD

    Finally I've completed my "callbacks vs. includes" experiment and here is the summary:
    • XCache is good for your health. With XCache there is absolutely no difference between callbacks and includes, not to mention things go significantly faster.
    • Without XCache includes are 5% slower than callbacks in loops and both are almost the same in normal hooks.
    • It takes 2 minuts to convert 1 plugin part to a callback.
    To conclude it, callbacks are not so great on performance as we supposed. If 5% is really important for you, then your site is popular enough to run a dedi/VPS or at least ask your hoster for XCache.

    So we will focus on improving includes() and architecture changes won't be so dramatic.

    This is good news. Thank you for your work!]]>     Thu, 11 Jun 2009 08:34:16 -0000     Trustmaster
    Auth system is quite painful. On one hand, we want it to be more detailed and have control over every option and every group (some people even request control over every user). From security point of view, ACL alone is not enough and is combined with hierarchical model. But even as it is now, auth system is huge data and slow access. I'm afraid before we add more and more items, we need to find some smart ways to make auth system more compact and faster access.

    UPD

    Finally I've completed my "callbacks vs. includes" experiment and here is the summary:
    • XCache is good for your health. With XCache there is absolutely no difference between callbacks and includes, not to mention things go significantly faster.
    • Without XCache includes are 5% slower than callbacks in loops and both are almost the same in normal hooks.
    • It takes 2 minuts to convert 1 plugin part to a callback.
    To conclude it, callbacks are not so great on performance as we supposed. If 5% is really important for you, then your site is popular enough to run a dedi/VPS or at least ask your hoster for XCache.

    So we will focus on improving includes() and architecture changes won't be so dramatic.]]>     Sun, 03 May 2009 14:08:49 -0000     Elgan
    however for now. SKimming through, All i see is for an update.

    new functions etc. Nothing really drastic or inspiring. just sed_ functions. WHich can be added and used to enhaunce plugins. Then make them more powerful. I find the trouble, have done in the past with not being abole to hook where i need to.

    I never used 125, but since cotonti and the install,uninstall thing, Ive finally been able to create some install scripts. Don't forget you can clear plugin body to get yourself a fresh page. Load tpls etc still if need be. I think its safer to not just load an SQL file. Now we have part install. We can do that from there if we wish. I give the user an options.

    I also find myself recreating admin panels within the plugin. Something should be done about this.
    We should have more access to groups, and auth systems. ive recreated groups in my admin panel ice created. With auth systems that are editable for the plugin. Now thats fair enough. ironicly the groups etc and admin panel is probably neater in my plugin than all spread around cotonti.

    but what im trying to say is. In order to create the groups, and the rights system, i just borrowed code from cotonti. However i copy/pasting and slightly editing functions that are only found within admin pages of sed/cotinti and we have no access to as a developer. for example the rights parse line. Ive copied and used in my functions.php. I call it from categories and from groups to just parse the rights pulled from the rights table.]]>     Sun, 03 May 2009 08:47:12 -0000     urlkiller isnt there some sort of SQL= (never seen anything here) in the setup file?
    i think this is maybe the rest that remained... never seen it used, yet.

    would like to have a
    SQL=mediaBay.sql
    to describe a file that should get exe when hitting install!
    edit: to descibe one if no mediaBay.sql exists in sql folder...


    @TwistedGA
    yeah, in fact he's right. its a rough easy system with the plugins.
    if iam remembering right there where a time when we had plugins and extendet plugins, right?
    isnt there any possibility to maybe have 2 plugin api's ? like one for advanced plugins using a shitload of code and the normal ones (the sed style ones)?]]>     Sun, 03 May 2009 08:07:00 -0000     GHengeveld Mon, 27 Apr 2009 04:23:42 -0000 Trustmaster # Koradhil : Just something I came up with.. wouldn't it be nice to have Cotonti automatically run the sql file (if included) when a plugin is installed through the adminpanel. Perhaps with a seperate authentication step so the user knows his database is being modified by the plugin. This would save the hassle of having to use phpMyAdmin to install a plugin.
    Actually I feel this should also be implemented for installing Cotonti itself (using a dedicated install script).
    It was implemented a while ago (starting with Sed v125) and is know as install/uninstall scripts. For example see modlist, markitup, attach and some other plugins.]]>     Sun, 26 Apr 2009 23:21:41 -0000     TwistedGA Sun, 26 Apr 2009 14:11:29 -0000 GHengeveld Actually I feel this should also be implemented for installing Cotonti itself (using a dedicated install script).]]> Sun, 26 Apr 2009 04:36:35 -0000 urlkiller
    its because most low-level plugins (sorry for that) don't have access to the db due to its more to learn for the new developer... so they just let this part out and find some other and not so well working ways to emulate a db, flatfiles etc...

    the query thing was just a quick idea where i was thinking would attract a lot more ppl to do their own plugins.

    but as i tried to say: make this last. first priority should be the redesign and interoperabillity of cot plugins system itself.

    btw. i voted brand new!
    but i have to admit i will be crying to the good ol stable system goodbye!
    and we should think about that making it as BC as possible to the old system.
    or developing a new plugin that has the possibilty to do so...]]>     Sat, 25 Apr 2009 00:47:17 -0000     Trustmaster Fri, 24 Apr 2009 20:18:15 -0000 Kilandor
    Not to mention wouldn't this cause alot of overhead, since lets say an average page, has 20 queries?]]>     Fri, 24 Apr 2009 04:47:40 -0000     Orkan 8. SQL query hooks.
    There are some important queries that a plugin developer would like to modify before they get executed. For example, if you want to affect forum posts order and join it with another table.

    Here is my very simple implementation of this idea: http://www.cotonti.com/pastebin/31
    I made it for one specific project, where the "query" is passed to several functions modifying it, before it gets executed.
    Of course, there is much room for improvement,
    Could be done with something more sophisticated, like php class with methods: addWhere(), addJoin(), addOrderBy() etc...]]>     Fri, 24 Apr 2009 04:27:55 -0000     Kilandor (Similar to pause/unpause but for installing)

    Truthfully compared to many other systems I think our plugins are very easy to develop.

    Its just straightforward php, I've seen plugins for wordpress and stuff having to convert them, and the code is a pain in the ass to convert.

    Any of our plugins if someone wanted could relativity easy to any system, or just use it standalone.]]>     Fri, 24 Apr 2009 01:44:23 -0000     Trustmaster
    urlkiller:
    i think a more developer friendly sql install should considerd as well as maybe upload packed plugins that get unpacked by the system. would make it far more manageble for the users after.
    # yeah, upload a rared archive and the system installs. no ftp crap anymore.

    # update function O_o cool would be if you had an external api connection where a file is checked if the installed version is still up to date. if the server is allowed he downloads the new file from server, if he's not allowed he simple announces that a new version is available. this would be very very helpfull in support and bugfixing because everyone would have the latest version. of course this would be a optional feature for very huge plugins. (iam talking here about how hard it was to keep track on every single usergal release.)
    Live update isn't very hard implementing. The only reason that makes me feel skeptic about it is security. For this you need to make files writable for PHP. It drops security level by nearly 30%, considering how many hacks were done using TPL Editor plugin and such.

    urlkiller:
    # while working a lot with ajax its bad that always the whole page gets loaded. would it be possible to have special plugin functions for a second db conection for ajax content? or more like a build in ajax query on the db. where you can execute, edit, add entries?
    Take a look at AJAX parts in plugins and a markitup example.

    urlkiller:
    # google apis java librarys!! can be defined in config and get's properly installed in <head>
    i know jquery is there for me, but sometimes the jquery misses some of the kick other libs have...
    No need to enable support for every single JS library available on the net. You can switch jQuery off in Admin. We should also implement a compatibility mode option.

    Orkan:
    Anyway, I just wonder how you'll gonna implement event registering and broadcasting system without OOP?
    Do you have any rough ideas to share at this stage?
    Don't forget, OOP has procedural code inside. And event handling is done with callbacks.

    Orkan:
    I like your "collected suggestions" very much. The 8. SQL query hooks could be done in arrays, I have similar idea already implemented in one of my private projects.
    Could you post your snippet in pastebin?

    Once more, I agree on most of the other points. And our aim is to make plugin development as easy, flexible and clear as possible.

    As for interconnection APIs via SOAP, XML-RPC, etc... First we make our internal API, then it will be easier to export some of it to the outer world.]]>     Wed, 22 Apr 2009 12:26:53 -0000     GHengeveld
    I voted Brand new, because I feel there's a lot that can be done to improve the current system, but it's better to start over to prevent clogging the code. Also I think there are improvements that will need an entirely different base to work with. Even though the current hooks system is quite conveniënt and works well for most applications, implementing an entirely new system could make things much easier for us.

    I think the new system should be mostly about keeping things easy and simple, so developing a plugin will be easier. The code required to 'install' a plugin and hook it up should be kept to a minimum and should also be well documented. I'm not so much into the technical details of implementing a system like this, but I've seen some welcome ideas in previous posts that I would like to see implemented.]]>     Wed, 22 Apr 2009 05:54:21 -0000     esclkm Wed, 22 Apr 2009 05:16:12 -0000 Orkan
    Anyway, I just wonder how you'll gonna implement event registering and broadcasting system without OOP?
    Do you have any rough ideas to share at this stage?

    I like your "collected suggestions" very much. The 8. SQL query hooks could be done in arrays, I have similar idea already implemented in one of my private projects.
    What I would like to add here is the cache system for plugin hooks. I think its possible to join all php files attached to a hook into one file loaded by system instead of include() all the hooked files separately.

    Kort:
    There are just 37 plugs in the downloads/plugins. Why worry? Brand new.
    dont forget about hundreds of private plugins

    I will vote for Minor update because of BC.
    Brand new or Major upgrade sounds to me like completely new CMS with some functions attached from old Seditio framework ;-)]]>     Wed, 22 Apr 2009 05:03:52 -0000     urlkiller
    making a fresh start, heh! just shooting some ideas in the pool...

    # maybe its cool to have a flexible config system. like a myplug.config.php that gets included auto. where you can define more and flexible new rules and settings for the plugin itself.

    # more easy integration of the core features: tags, comments, ratings, textboxer etc. nice would be a cot_create_comments('bla','bla','bla'); on any of the functions.

    # while working a lot with ajax its bad that always the whole page gets loaded. would it be possible to have special plugin functions for a second db conection for ajax content? or more like a build in ajax query on the db. where you can execute, edit, add entries?

    # google apis java librarys!! can be defined in config and get's properly installed in <head>
    i know jquery is there for me, but sometimes the jquery misses some of the kick other libs have...

    # sql query injection sound a bit bad... i would like to see a more low -level programmer friendly sql query system. integrated and easier to understand left / right joins and etc.

    query('table','field LIKE %BLALBA%','some more sql','ASC');

    some sort of that, dont know. if you don't like its anyways cool for me.

    # multihooking, cool!

    # yeah, upload a rared archive and the system installs. no ftp crap anymore.

    # auto chmodding of the files / folders. info from config file!?

    # update function O_o cool would be if you had an external api connection where a file is checked if the installed version is still up to date. if the server is allowed he downloads the new file from server, if he's not allowed he simple announces that a new version is available. this would be very very helpfull in support and bugfixing because everyone would have the latest version. of course this would be a optional feature for very huge plugins. (iam talking here about how hard it was to keep track on every single usergal release.)

    # quick question. we are not only talking about the installation syste here. in short we're talking about making the developer / designer API more aprehensive for any type of developer. if we would had a sort of toolbox like in most other distributions we would interest more low -level and high -level programmers to develop for cotonti, thus makes us more noticed...
    to be true first i was missing the huge documentations on seditio but then after some days of code browsing i was thinking that this is some sort of very stable and reliable system. i was missing most of the integrated features from other systems, wich, of course made them more complicated. but what aout haveing cotonti offering a broad array of predefined tools.

    not only this will help develop a new type of plugin. if its easy to code more plugins will be made. more ideas will flow into the project. the more recognised it will be.

    ok that would be enough for today. maybe i got some more ideas. dont' start coding yet ;)]]>     Wed, 22 Apr 2009 02:09:33 -0000     Kilandor
    • New hooking features, multi-hooking(same file multiple hooks), timer based hooks(ex, a cron sort of thing)
    • All configs, settings etc, should be code, not the commented crap(leave old method for backwards compatibility)
    • Advance install/uninstall API, IE on install before or after core install, it can be set, to code your own menu/options, or atleast flag options to come up, ex On install ask if they want to drop a SQL table and re-add it, or ask if they are upgrading, to run upgrade code, on uninstall ask if they want to drop it.
    • New functions that are friendly for Plugins, such as easy config change functions, etc
    • Prob more but i'm drawing a blank now.
    ]]>     Wed, 22 Apr 2009 01:00:02 -0000     esclkm Tue, 21 Apr 2009 23:24:09 -0000 Trustmaster
    1. Remove SED_EXTPLUGIN block from every single plugin file. In fact, it is more annoying and redundant rather than useful. "Code" is the same as plugin name. "Part" can be identified by file name. "Hooks" can be binded in setup file (see below). "Tags" are better to be collected they way "tpltags" plugin does it (by scanning the code instead of forcing plugin developer to describe every tag). "Order" can be specified in hook binding.
    2. Specify hook bindings as an array in setup file like:
      $hooks = array(
	array('filename1', 'hook1', 10),
	array('filename1', 'hook2'),
	array('filename2', 'hook3', 99)
);
      where the third optional parameter is priority (order). As you can see, it also allows for multiple hook bindings.
    3. Automatically preload plugin permissions into $usr['auth_read'], $usr['auth_write'] and $usr['isadmin'].
    4. Automatically preload plugin langfile.
    5. Already added in tickets: simplify CODE check. It can be
      defined('COT_CODE') or die('Wrong URL');
    6. Time to change sed_ to cot_

    More brainstorming while writing a plugin:

    7. Auth hooks. Add ability to affect auth in exact places (already known as EYOOP issue).

    8. SQL query hooks. There are some important queries that a plugin developer would like to modify before they get executed. For example, if you want to affect forum posts order and join it with another table. Currently queries are executed like $sql = sed_sql_query("SELECT ..."), so the only way to change it is either a corehack or another similar query. If we did it like:
    $query = "SELECT ...";
forums_posts_query(); // HOOK here
$sql = cot_query($query);
    it could leave a possibility to edit the query with a plugin before it gets executed. It's not the most elegant way to modify a query, but if you know a better way, don't hesitate to share.]]>     Tue, 21 Apr 2009 19:17:16 -0000     Lissbol # esclkm : If we will rewrite it in every version - our CMS will be not so attractive for developers

    agree with that if Cotonti is going to have a chance in the future vs. WP , Drupal etc etc then über major changes can't be made in every release.]]>     Tue, 21 Apr 2009 17:36:57 -0000     Trustmaster
    Now it is time to start a research and learn what exactly we are going to change. So please request features you would like to see in Renaissance as a plugin developer. Our overall goal is to make plugin development as easy as possible, flexible to implement almost anything and still strong enough and bug-proof.

    Then we discuss these features, select those worth implementing and after that form project details for the API upgrade.]]>     Tue, 21 Apr 2009 15:06:06 -0000     tensh What do you miss in this system?
    Because if you want to change something that is working fine, there must be a strong reason to do so.

    I agree that plugin API, if changed, must remain the same for a loooong tiiime.]]>     Tue, 21 Apr 2009 14:38:45 -0000     esclkm But in Renaissance we need new stable concept, which must be not edited or rewritten in new versions.
    If we will rewrite it in every version - our CMS will be not so attractive for developers]]>     Tue, 21 Apr 2009 13:32:26 -0000     Trustmaster
    There are 37 plugs here, but a hundred more inherited from Seditio here and there. Keep in mind we can loose em all. If it is ok, then Renaissance has a chance to be something different, whereas Genesis will stay for long-term backwards compatibility.]]>     Tue, 21 Apr 2009 03:00:05 -0000     Kort Mon, 20 Apr 2009 23:56:01 -0000 aiwass
    Those things should be :
    - Custommetas (The admin can set what keywords he wants on any pages, events, forums etc. he wants. SEO at it's best)
    - Events & Calendar should not be a plugin, it should be standard.
    - Trackbacks as well
    - Related Pages (SeeAlso is a plugin today from LDU/Seditio)

    When we talk about API's there should be a API that, at least in parts, work externally for other sites to integrate with your site (Ex. Youtube, Digg, SoundCloud, Facebook etc.). By thinking of this when work begins on designing an API for Cotonti, would make it more viable for future users and also be an incentive to plugin builders/module builders to create based on versatility.

    If we go for Brand New, then the above stated would be made as standard, at least i think so. Maybe even go as far as stating that all todays plugins are standard features included and the API opens new doors and development concepts for integration and involvement of Cotonti based "Brand New"-Plugins.

    I would even go as far to say that it might be the only way to separate from the old Seditio way of making, integrating and developing of new features, which is now translated over to Cotonti, as it is based upon Seditio-N.

    Personally i would go for Brand New, since i love technology and smart new features, even though, those stated in the beginning are old as hell, but they serve a good purpose and they are standard parts of other CMS/Frameworks out there that are commitment/community driven projects.

    Vote is BRAND NEW]]>     Mon, 20 Apr 2009 23:55:50 -0000     Trustmaster
    Brand new - is likely to be new plugin abstracts, reviewing everything on what plugins are. I haven't thought what it could be. Just means that no old plugins will work at all.

    Major upgrade is most likely to be based on callback functions. So every plugin part will be a function. You can bind it as a handler for several events at a time (aka hooks). When a module is run, it preloads plugin includes so all necessary callbacks are compiled and binded. A hook calls the callbacks due to their order. Most changes inside of the plugins are related to making them functions, meaning also that they will need to access global variables explicitly.

    Minor update is about adding extra functionality without changing the concept of plugin parts (which will stay as includes). Just extend sed_plugins to bind the same part to several hooks, improve auth handling and implement a few other requested features. There still be changes in plugins, but most of old code will work.

    I just want to warn that if you vote for "Brand new" or "Major upgrade" that would mean that old plugins will need some work. I'm not sure there will be enough enthusiasts to do it.]]>     Mon, 20 Apr 2009 14:16:40 -0000     Dayver Major upgrade because from my point of view, this is the optimal ratio between the new opportunities that are provided and the complexity of changes to the old plug-ins
    ]]>     Mon, 20 Apr 2009 08:44:01 -0000     Elgan
    It would be nice, Im also thinking of some sort of setting auth functions as well as getting auth, as you have to grab authing for each new created user group.

    admin needs to be more plugable if we want proper intergration, atm ive left all my admin in my plugin, as its easier, plus all my admin is in 1 section then. HOwever, its still seperate from the engine admin and i have to provide 2 admin links.

    ive never actually needed to multiple hook, Its just easier to make a function if its code thats going to be duplicated.]]>     Mon, 20 Apr 2009 04:38:58 -0000     Trustmaster
    In this topic I'd like to ask about Plugin API. We want plugins to be a little bit more flexible, hook into multiple places, etc. There is a really interesting idea of implementing plugins as event handlers and making a move towards event-driven behavior. But what worries me before I start to make API concepts is how far plugin developers are ready to go.

    So I wonder how much backwards compatibility there should be. Here I explain poll options:
    • Brand new - the API is something revolutionary, but all the existing plugins will have to be rewritten. Almost no backwards compatibility at all.
    • Major upgrade - event-driven design, flexibility benefits. Will require changes in interface part of all the plugins, but the actual code will stay the same. It's about changing 10-30% of code in plugins.
    • Minor update - just try to add multiple hooks keeping current design. Will require changes in plugin headers (currently known as SED_BEGIN_EXTPLUGIN). 3-5% of changes in code and old plugins should work too.
    • No changes - just leave the plugins alone.

    Please explain your choice, especially if you are a Team member.]]>     Mon, 20 Apr 2009 03:09:14 -0000