TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Common practice = module sharing
  • Before I used Kohana as the basis of my websites I used my own library but the workload of creating everything myself and the stupid feeling off 'reinventing the wheel' drove me to find a common framework and the best i could find was Kohana.

    Kohana is a great framework that can be used in many ways and suit many needs. I know kohana is not a CMS it's a foundation for a cms. That is off-course a great strength, but as a result of this, the CMS systems that people build can not easily share modules because they all work in slightly different ways.

    And therefore that old feeling off having to reinvent the wheel is creeping up on me again. Why is there not a common 'blog' module allready for example or a 'page' module , I'm shure we have all built one.

    I was wondering if there are folks out there who, like me , would be interested in finding a common 'best practice' that would make module sharing more easy. I thinking af a basic CMS that would handle users and roles and would allow modules like 'blog' , 'shop', 'pages', 'images', 'documents' , 'comments' , 'main_menu' or whatever. That way we could all benifit from each others work and not sit in isolation an build the same things in a hundred different ways.

    Does this make sense?

  • It does.

    I'm not entirely sure how many people have already built a 'generic' cms on kohana instead of site specific back-ends. Have you seen s7ncms? I've looked at it a bit and it already seems to be the 'basic CMS' you describe above (it has a blog module last time i looked ; ). I think it will be quite tricky though to find consensus in the way modules are to be set up.
  • I gues what is needed is a good idea for a design of how the modules should be set up. (plugins would be a better word)

    Yes s7ncms, is very nice and has a great install process. I was not aware of the blog module. maybe s7ncms could be the starting point. I guess its just a question of doing it.

    Whenever I build something there is allways the balance between 'generic' reusable code and site specific. Reusable code is often the goal but I seldom have the time for it. The site specific code is what gets the job done but does not make the job easier the next time. I find that if you aim at reuseable code you are taking a chance: Will you really use this again? Does the extra time it takes to develop pay off? Who knows what you will build the next time?

    If a common generic kohana cms existed with a modul architecture then the incentive to glue you current project into the larger picture would be greater.

  • For this to work you need a good foundation. For my own cms I use modules but quite differently than s7ncms and would be hard to make it compatible. What you're asking is not to standardize modules but to standardize a Kohana cms, which in itself will be a new project. Such a project would be great but hard to accomplish.

    Reusable code like Forge,Temper,Grid, a Spamcheck module or any other library will be easier to achieve and easier to share.
  • I think your points are all valid dlib, yes it would mean a standardised Kohana CMS.

    In order to stay in business I find it vital to have at least a core skelleton of a cms that I carry with me from project to project. This skelleton app covers basic functionality and allows me to quickly get something working so that i can focus only on what is out of the ordinary for this particular project. Very seldom do I start completely from scratch. When ever i have to rewrite my skeleton app that is when I experience low income periods, for instance if I change to a new framework (like Kohana) or because new-found knowledge prohibits me from reusing 'stupid old code' , simply because it takes time to carve out a path to a working actual working commercial grade product.

    Once i have found solutions let's say to how to build a admin interface I tend to reuse this way and slowly build a library of code that helps me do it again, better, faster. Only deviating from the basic solution pattern if it really can't get the job done. I find that the more consistent, in terms of sticking to well tried solution patterns I can make my project, the faster I can get it done. if I do the opposite, say If I use Forge in one controller Formation in another a custom built form in a third and so forth, I simply end up increasing the complexity and my error rate goes up and productivity down. It' s nice to have all these options but what I really whant is a solution that I'm familiar with that I can refine. The important thing is that I have some solution that works and that I stick to and built upon. This is where real value is created.

    I think we all have a code-base that we reuse from project to project, all I'm saying is that maybe we should post these skeletons so that schools could be founded around them, modules could be written for them, and newcomers could get started and learn from them.

    Think of it as an intelligent default. An intelligent default application of all the tools in the Kohana toolbox in order to actually create the basis af a production CMS. I know there is potential for huge battles over what is intelligent and what the thing should actually do. I personally wouldn't mind if some genius from the core team had the last say in what constitutes intelligent :) The important thing is that some sort of common ground would be laid out. I think the value for the community would be enormous.

    Well maybe I'm just dreaming and maybe it's just because I'm having a hard time carving out a good standard practice for myself..(I seem to have painted myself up in a corner with insisting on using Forge for everything in the admin ) but now at least my thoughts are out there...

    /Martin

  • When we used CI @ work I wrote a set of tools for internal use called Xpress. I couldn't at the time release them because it was done on company time.

    However they built on top of the CI framework to add lots of tools and functionalty that let you build apps quickly (libs like Xform for example, or Xtheme for managing themes.. which was important at the time). It wasn't so much an admin interface or blog library or whatever but a selection of tools that could be used to build such apps in just a few lines of code. I found that much easier to work with than a set "generic CMS". Importantly they were very strict MVC.

    At my current company we dont build web stuff much (though when we do we now use K2) so there was no call for these tools - but Im going to try and write them from scratch in my free time :)

    Current list of tools plan:

    Libraries

    • Xtag: tagging, templating and parsing library (currently supports Geshi, BBcode, Markdown etc.)
    • Xtheme: theme switcher for views (not started) (this also makes views closer to strict MVC style)
    • Xsettings: database some of your settings (I fond this VERY useful in CI)
    • Xgrid: this is more a dev tool, a sort of auto gid tool. I used it as a replacement for PHPMyAdmin back in CI days
    • Xform: proper (strict) MVC form generation
    • Xmodeller: a slight remake of the generic model to make it more strict MVC
    • Passport: Very very simple auth system (login, logout, user tracking, basic profiles. No account control)

    Helpers

    • Xtools: a variety of stuff that wouldn't fit in the libs :)

    Modules

    Stuff that doesnt fit as a simple library * Endorse: Adds full ACL to passport

    (there are a few more but I don't want to give out my ideas :P) I've laid down a bit of the code for this but it's a long way off completion (and Im adding more ideas daily).

    As an example using the CI variations of these (bearing in mind a couple of the libs weren't there before and there were a few that Kohana has made null and void :)) a 2 man team could deploy a fairly complex shopping site in under 3 weeks (our record was a full company site in 2 weeks 1 day) including design stages.

    If anyone wants to help out (properly) drop me a line.

  • At the moment i'm working on a blog module, with provide basic content storing like author, create date, content, extended content. Commenting is also available. Unfortunately i'm rework it over and over again, trying to find the best coding/coding style....

    If someone interested in, i can share the code.

  • I get your point Errant, rather than settling on a specific implementation and turning Kohana into just another CMS (The world has no shortage of free CMSes) you view Kohana and a your toolbox as more like an instrument that the developer plays to produce different songs (websites) . As apposed to playing the same song over and over again. You abstract out the problem , take it to another level. And combine it with other toolboxes like jQuery, Mootols or sproutcore. I think this is probably a more pragmatic way of viewing things and one that resonates more with the core spirit of Kohana. But also one that places a heavier burden on the developer. He/she must be able to play that instrument as there are no rails... And off-course pocess the toolbox in the first place.

    The libs you outline sound impressive as do your production speeds. Surely they would be a welcome extension to Kohana. I guess this is where we are today. The core team is slowly but surely adding to the toolbox that is Kohana. Somebody just have to write them (in their own time) first...

    If someone has can outline a good general way of creating admin back-ends then I would be more than interested in leaning how as I'm hitting all faul notes a the moment...

    /martin, slightly out off tune.

  • I'm hitting all faul notes a the moment...

    Hey no way! Each person has their own ideas... I like the idea of a very simple, generic CMS with plugin module functionality and I can imaigne how that speeds up production! It just seemed a good thread to present my approach - bearing in mind that the kind of sites I developed in the past were very different form each other (and didnt suit a generic CMS model very often).

    Regarding a back end / admin controller. For CI I just used our ACL for authorisation and a combination of one of the form builders and a database model we put together to make admin pages for each functionality required. Thinking back we did have some "default" admin tptype controllers (like a page manager) which I guess constitutes the CMS idea you were mentioning.

    As you said though, it is definitely worth trying abstraction tools like these. You said that our delivery time was excellent - it was good, but bear in mind that down time was spent maintaining the tools (which took while at times). Also that we "specialised" them so that for X type stie you could just drag and drop a code base and it was just a case of adding a few lines of code to your models and creating the views. We had other tools to use as shortcuts as well (stuff we wrote in Python to automate as much as the process as possible: for example we had quite a nice script that packaged it all for installation including grabbing the SQL layout and so on saving hours of work).

    Your right though: tools that have a steep learning curve or that you dont quite understand are fairly worthless as time savers :P

    My thinking has always been that the closer you can get to a generic CMS style framework without formalising it to an actual CMS the faster development is :D

    (sorry just throwing ideas and thoughts out there :))

    @Dryon: I know the feeling. I've reworked my personal site(s) over and over and I'm still not happy with them :P

  • dyron , I would like to have a look at your blog efforts as I'm currently re-evaluating the way I'm coding my admin/back-end pages.

  • dyron, please share with us!

    ps: tell me your icq# oder jabber-id.. i have some questions :)
  • Hey Errant, I'm glad you understand the idea, maybe we can cook something up together. You know like an empty skelleton site we could throw back and forth that gradually could flesh out as we implement dlibs ideas from http://learn.kohanaphp.com/ or our own timesaver libs...maybe have a nice installer rutine like edys cms....

  • I'm all up for making a repository of some kind with great libraries so the making of a cms or any other application is made easier. All my code releases essentially have been for that purpose :) I do like the word timesaver libs because that's what it all comes down to. Having good code available to us will help us all.
  • I am using kohana at my work and am building up modules to accomplish different things, i cant release the source code either, but i can say i built modules for things like a simple cms, or just user authentication/admin auth and user management. One feature i wish kohana would have that i put into my modules, is a simple built in way for one module to only function if another required module is present(for instance my admin module requires both forge and auth modules to be present, but you can obviously use either module with out having to use my admin module)

    but other then that, i wish we could have a collection of modules that simply supply a simple feature, and require off each other, to prevent duplicate work, a CMS that requires an admin module... so if i dont need a CMS, just the ability to manage users... the admin module fits my needs, but then i always know i can add a CMS later... so who's gonna take this idea and make a google code repo we can all contribute to?
  • well since i started this thread maybe I should get off my fat ass and make the repo.

  • not really sure that another repo going to be usefull, there's a third party kohana modules repo working under Google Code http://code.google.com/p/kohanamodules/
  • precisely, I think that if we make a new repo it should have a different purpose than the 'kohanamodules' repo. I think it should be a fully working kohana app. It should be the starting-point for an actual production class CMS that i have tried to outline above. I think that making it into a concrete working app is the only way to expose and address the challenge of module interoperability and 'best practice' in general. What do you think?

  • I'm willing to donate code to such a app/repo :)

    Not really got the time to kick start it / organise it tho ;) mkjems: if your up for it then awesomeness!

  • The best starting point is:



    Shadowhand

    Convention over configuration



    This means we have to set strict conventions, e.g.



    • Do we use Forge, Formation or nothing?
    • Class name and function name conventions, /blog/article or /shop/article
    • Coding style
    • ...


    I think there are two ways for such an CMS.




    1. First one is the CMS module itself. This means 'blog', 'shop', 'gallery' are plugin classes as is. If you copy them in the plugins app/modules folder, they work (accept from DB table creating, fitting the configs). And needed libs are easily included with the libraries folder, e.g. a spamcheck lib.


      Posted By: mkjems

      [...] I know kohana is not a CMS it's a foundation for a cms. [...]


      But I think this breaks the intention of the Core developer and yes, then Kohana acts like an CMS, which should not.



    2. We use the given module architecture.


      I 'll try to create a blog module like the auth module. Showing in the Blog_Demo_Controller how the Frontend works, the same with Blog_Admin_Demo_Controller. So, everybody can look how it works and made a costum controller and the belonging views on his own. Therefore the application logic belongs to the Blog or Blog_Article libs, not to the Controller itself. So Forge, Formation or hand written template filling is easy to made.


      Some 'disadvantages' of this system is we depend on other modules like auth or Forge. Besides you have to create a common module which contains all controllers, models, views needed in the whole app.


      That's the way i prefer, because it's the way the Core developers mean the app structure.




    Maybe some input of the Core devs would be nice, if my understanding goes the right way, or not.



    My suggestion of the folder structure



    • administration // Contains the backend app
      • controllers
        • blog.php // Based on Backend_Controller and blog_admin_demo.php

      • libraries
      • models
      • views

    • application
      • controllers
        • blog.php // Based on Frontend_Controller and blog_demo.php

      • libraries
      • models
      • views

    • modules
      • common
        • controllers
          • frontend.php
          • backend.php


      • blog
        • controllers
          • blog_admin_demo.php
          • blog_demo.php

        • libraries
          • Blog.php
          • Blog_Article.php
          • Blog_Categories.php
          • Blog_Comments.php

        • models
          • Blog_Article.php
          • Blog_Categories.php
          • Blog_Comments.php
          • Users.php

        • views
          • blog
            • article
            • article_form // Or use forge

          • comments
            • comment
            • comment_form // Or use forge



      • gallery
        • controllers
        • libraries
        • models
        • views

      • shop
        • controllers
        • libraries
        • models
        • views


    • system
  • I also think we should use the given module architecture. And I think the folder structure you outline looks good. I'm not sure I understand the purpose of the common module though.. but hey! great post!

    I'm not gonna hold you back if you wanna get started with the blog module right away I will set up the google rep immediately.

  • Your admin and front-end applications should be different apps, rather than having it nested in the front-end application. With modules, it's just as simple to do it that way, and much easier to do configuration without adversely affecting the front-end.

  • Ok, that sounds like good advice to me.

    I greated a google repo called http://code.google.com/p/common-sense/ ...well so far its just an empty project.

    Guys, if you want to contribute just mail me: mkjems[at]gmail.com or tell me your google email address.

  • I think what shadowhand means is something like what's described here: http://docs.kohanaphp.com/installation

    • webroot
      • index.php (website bootstrap)
      • admin folder
        • index.php (admin bootstrap)
    • kohana system folder (shared)

    Maybe we should settle for a solution where the Kohana System folder is shared but where everything is inside the webroot to begin with this makes it easier to toss around.

    • webroot
      • index.php (website bootstrap)
      • application
      • modules
      • admin folder
        • index.php (admin bootstrap)
        • application
        • modules
      • kohana system folder (shared)
  • Indeed, multiple Kohana application directories with a shared system folder and possible shared include paths
  • I would prefer 2 app (frontend and backend) with one module folder and system folder.

    Accessing both via .htaccess rewriting

    index.php => loading 'application' app admin.php => loading 'administration' app

  • @dyron: That sounds like a perfect solution, and cuts out one more bit of complexity. Good suggestion.

  • @Shadowhand: Thanks. I takes me only 4 months to come to such a solution. *g*
  • What will be the best URI routing strategy then in regards to the admin access ?
    Let say we manage news in the backend.

    http://example.com/admin/news -> Main panel
    http://example.com/admin/news/add -> add form
    http://example.com/admin/news/edit/4 -> edit form for news 4

    Do we create an Admin_News_Controller, with inside function index(), add(), and edit(), or use 'add', 'edit' as arguments of the news() function inside an Admin_Controller() ?
  • Great! Dyron, can you supply me with the .htaccess file ? I will go and establish the basic file structure in the svn repo.

  • @Delapouite: There is no Admin_Controller, there is only News_Controller (with index, add, edit, etc).

  • @mkjems: this was my .htaccess in S7Ncms until r94

    i changed it because i want a module to be "drop in" => you download a module, extract it and drop it only in /modules (frontend and backend)
  • this is my current .htaccess

    Admin access via subdomain.
  • I set up a basic kohana site along the lines we discussed, http://code.google.com/p/common-sense/, we should now have

    admin.cs.dev
    cs.dev

    however I can't get admin.cs.dev to reach cs.dev/admin.php. I allways get the frontend. Maybe it's the way I have set up the virtual hosts.

    DocumentRoot "/opt/local/apache2/www/common-sense" ServerName admin.cs.dev Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all

    DocumentRoot "/opt/local/apache2/www/common-sense" ServerName cs.dev Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all

    I also have a host file with :

    127.0.0.1 admin.cs.dev 127.0.0.1 cs.dev

    ...hmmmm

  • With my .htaccess i don't need two VirtualHosts, the subdomain is catched by it.

    Maybe you have to set:

    ServerAlias *.cs.dev


    Another suggestion:

    I think "common-sense" is an unfavorable name for the project, which doesn't point exactly the goal. "common-sense" of what? "kCMS", "kohanaCMS" or "kBasicCMS" with a detailed description like "This is a project driven by the Kohana community (note: not the core devs) showing a common-sense or good coding style for a Kohana application." may suit better.
  • well ok, I will change the name.. how about : kCMS

  • I agree with Dyron.

    BTW if there is anything not yet snapped up that needs coding let me know and I'll try and start putting code together

  • todo list:

    0) delete common-sense google repo.. DONE! as I also have to agree with the points made by Dyron regarding the name and description.

    1) Find a name : kcms (sounds cool, but is a radio station and is very used name already for a lot of things on the web) kohanaCMS (allready taken as a google project) kohacms kBasicCMS fastkohanacms kstartcms

    2) Set up new an inproved google repo (mkjems)

    3) Create initial skelleton along the lines already discussed (mkjems)

    ) Create an actual commonly used module (Errant? Dyron?)

    ) Put conventions into words...difficult before we have nice examples first I think.

    ) Put Coding style into words ... How about using the same as Kohana? Why not?

    ) Is it ok that we use the kohana forum for collaboration on this project?

    ) specify project goal or mission statement if you will.

    ) Create a 'roadmap' , lay out some 'milestones'.

    Anyway. How about that name? Let's have a quick show of hands and let's get that out of the way... I'm now for 'kohacms' !. What do you think?

  • I would prefer if you did not use Kohana in the name of the CMS, as per the BSD license. Thanks.

  • Respecting shoadowhands wish the list is now, well basicly empty as the 'k' or 'ko' stod for Kohana so I guess were are back to square one LOL !!!

  • At the moment my creativity is not as good to find a cool name. Maybe some input, again. Let's try to find a name on a base like "ExpressionEnginge", "MovableType", "Textpattern", "Wordpress" or "Typo".

    I don't know whether my basic blog module will be finished in the next time. I have my bachelor exams.

    Conventions and coding style can take from the Kohana Core, sure. I think we should keep near the Kohana Core.
  • ok come on guys we can do this!

    We need an original name that we can all live with. Preferably one that hints at: Community collaboration, Basic CMS starting point, skeleton .., Maybe some metaphoric abstract reference to Kohana but that has to be to the Native American (Sioux) meaning of the boy´s name Kohana is: swift or the Japanese meaning of the girl´s name Kohana: little flower. Something that makes cms development faster. Some sound way of thinking. Some omnipotent statingpoint.

    Over at http://www.opensourcecms.com there are a lot of cms names could serve as inspiration.

    The reason I picked 'common-sense' to begin with was that it can be thought of in two ways. 1) as the normal meaning meaning sound judgement. 2) common understod as 'what we have in common' the logic we have in common. Both of witch I thought fitted the project quite nicely... but I'm just gonna let that one rest.

    The list of new contenders:

    • publiccms
    • jointcms
    • cmsunited
    • instantlogic
    • supersonic
    • hastings

      ...to be continued...

  • How about SiteBase

    Very literal but kinda cool too.

    @mkjems: dont mind either way, co-own, member whatever.. :)

    Other ideas...

    • Moddish
    • KAdditive (I'm assuming K is k in the name! Shadowhand?)
  • @dyron : don't worry. I think we will only just have found a name by the time you have returned from your exams.. :)

    more suggestions:

    • typical
    • straight
    • square flower
    • big bird
    • normalcms
  • @mkjems: K or KO is fine, just so long as the full word "Kohana" is not in the name. Since this is not a sponsored project, it would be violation of the license to have your project use our name.

    Thanks!

  • how about "Kommunicate" or "Kohmmunicate".
  • i vote for Hanami. i like it
  • KoHanami? :] OK, OK, Shadowhand... :P
  • Hanami sound pretty cool. It has my vote.

    By the way, if you need a building block for a CMS I might have one. Some time ago I created a Head library, it renders the < head > section and you can add javascript,css files or code, set the title etc. Currently s7ncms uses it. It needs some work though on documentation, meta element and ordering support. I probably won't get around to it soon. If anyone wants to continue development for Hanami (?), you're free to do so. Of course you can also place it in the Hanami (?) svn repo so I can continue development (if I get to it) there.
  • Hanami +1

    Want to contribute:)

    My opinion is, that the heart of the CMS is an installation script (with a system of automatic plugin installation). And it has to be discussed first (and it has to be main criteria for folder structure).

    Each module folder may contain 'install' subfolder with standardized installation scripts.
  • Posted By: utyf

    Each module folder may contain 'install' subfolder with standardized installation scripts.



    No, this is not the goal of modules. They are not plug ins.
    Modules contains examples or demo controller like the Auth module. They provide their app logic in libraries connected with models and serves basic views for simple output, which everyone has to extend in their own application.

    Modules are not copy'n'paste and they magically works. You have to extend or customized them. For example, someone needs a categorization for the blog articles, another person wants a ranking, third one needs a expiration date and so on. The Blog or Blog_Article lib provide all of the features. So everybody creates his own controller which suits his requirements and the application developer combines provided classes/libs/methods/... as they are needed.



    PS. Now i understand the "we don't code your app" a bit better.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion