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
Presenting Wi3 : a modern and flexible HTML5 open source cms built on Kohana 3
  • Hello everybody,

    I've been mentioning here and there that I was building a modern Kohana 3 CMS, and today I celebrate that it has reached a first Alpha state! \o/

    The open source project can be found at Github on https://github.com/fabricasapiens/Wi3 . Installation instructions are included, but if you want to see a live version, you can send me a private message.

    I would much appreciate a 'watch' on the project...!

  • https://github.com/fabricasapiens/Wi3

    That's the link, the plonka posted it with a full stop on the end hah ;)

    It's not kohana 3.1 is it?

    I will take a look soon when I'm not busy, it sounds like it has potential.

  • Heh, thanks :-)

    Wi3 is based on Kohana 3.0.9 for the time being, but it will receive an update to 3.1 eventually!

  • Well done! Keep up the good work.

  • Hey Devi, thanks!

    I will keep posting some updates here now and then, when something interesting has happened :-)

    Next up is a demo page or a showoff to demonstrate the possibilities of Wi3.

  • I got the time to take a brief look at Wi3. At first glance it seems messy. I think you should separate the core from the demo if you want more people to use it. It's strange it's linux only while the Kohana runs on every OS.

    I read a few of the docs and it seems you started building the CMS using 3.0.7, i guess that explains the use of sprig. I think if you go on with it you should find a replacement as sprig-mptt isn't maintained anymore.

    I was curious about the multilanguage plugin because you mentioned it's only Dutch. There is a method where you return a language switch where the languages are hardcoded, that is just wrong IMO.

    I'm sorry i only mention the defects in this post. I will toy with it some more to get to the good stuff.

  • Hey Xwero, walking through your points one by one :-)

    1. could you elaborate how it is messy? The UI is meant to be very simple, so hearing this is a serious issue...
    2. The cms is not Linux only (on the contrary), but I use Linux myself, and have no idea if it works on other platforms. It should, but I don't have official support for it right now... Could anybody test it on other platforms? Especially Mac, since I don't have a Mac available to me anywhere...!
    3. Sprig might not be maintained anymore, but I understand how it works, and it does what I need. There is no need for a replacement any time soon :-)
    4. The multilanguage plugin is not about translating the whole CMS, but it is for making it possible to create a site in multiple languages. It is not feature complete, and the language-array should of course be extended. Could you create an issue for this on Github?

    Thanks for the help (it only makes the CMS better) and I'm looking forward to the positive side of the story :-)

  • Sprig might not be maintained anymore, but I understand how it works, and it does what I need.

    Just feeling like quoting a good sentence. Applies to any modules. Unmaintained != useless, especially in Kohana world.

  • When i wrote messy i meant the code structure not the interface. Most of the packages that are build for or using kohana are more or less drop and use, i'm spoiled so your CMS seems messy as i tried to make it work but it didn't.

    It was a brief look, and i didn't had caffeine yet. Maybe that is why it was all negative.

    I'm still wondering why the plugins are in a separate directory? They look a lot like modules to me.

  • @asyazwan I didn't mean unmaintained = useless. When a project goes unmaintained support is harder to get, which means if people use the CMS @willemmulder will be the first line of support. I'm not sure if he wants to take on that responsibility.

  • @xwero I can tell you the code structure is not that messy, but it needs some elaboration before you understand it. A lot like Kohana itself ;-) That it didn't work is really too bad, what errors did you get, or at what part of the instatllation instructions are you stuck?

    The plugins are indeed modules (just like the pagefillers and the pagecomponents) but they are only useful for the app itself so I just put them in the folder structure of the app to keep things where they 'belong'. This is of course a subjective decision, but I feel that this works best :-)

    @asyazwan So true! Of course @xwero is right that I would need to fix errors in Sprig as well, but I'm willing to take that risk since Sprig works correctly right now, and there will be no new Sprig-related things in the near future :-)

  • Sprig is still in development and is still supported. Not sure why anyone would think otherwise.

  • @zombor on github, https://github.com/banks/sprig-mptt, there is a message it's not maintained any longer.

  • Yeah, that's his mptt class, not sprig itself.

  • @willemmulder: A first quick try on my XP/Xampp didn't work - I'm sure I messed something up with .htaccess files. I will give it another try as soon as possible! Very curious!

    It would be great if you could explain somewhere (in the docs?) the reasons why you haver chosen a different application directory setup than kohana-out-of-the-box, and how it's expected to work. (Also - if possible - how to make it run with standard dir setup.) I'm sure you have good reasons, and I'm curious about them too! :-)

    Keep up!

  • @cambiata Thanks for trying it out! :-) Do you get any errors? Where do you get stuck?

    I have the directory setup the way it is, because it separates all important directories from each other in a 'logical' way (at least for me, that is ;)) and enables for quick access to the important parts of the application from the root folder. However you're right that I should document these kind of choices in a better way. Currently the docs folder holds a Dutch description (systeem setup.odt) of what I did, and why but its outdated and incomplete...

    Thanks for the heads up! I'm hoping to see the CMS working on your machine! As an additional plus it would also confirm Windows compatibility :-)

  • Hey Willem, tried it out yesterday too, but still didn't got it running after an half hour. I gave up after that, I will look into it in the weekend. Thanks for sharing your hard work!

  • Thanks for trying it out, and I'm sorry that it doesn't work...! Have you followed the exact instructions in the readme? I'm very much willing to help if you post any errors or anything here!

  • Hey Willem. Just saw your reply, so I gave it another try. There's something strange in my WAMP-config if I put my .htaccess in the root. So I'm further now, but I'm sad to say your project isn't fully Windows compatible out of the box. The first thing I noticed: strrpos(__FILE__, "/") doesn't work in Windows because paths use backslashes.

  • Hmm, the PHP manual says "On Windows, both slash (/) and backslash () are used as directory separator character. In other environments, it is the forward slash (/).", but yes, when Windows gives a path itself, it probably uses backslashes... Could you create an issue on github, I'll fix it as soon as possible!

    I will test it out on Windows myself as well... Hopefully tomorrow!

  • Indeed, it's just one extra line of code to change the paths from back to forwardslashes. I'll be glad to help fix those little problems (if there are any) in the weekend. :) Didn't do the full setup yet...

  • Hi Willem, will Wi3 work in a non-root directory? I tried in my Windows 7 with little success. Let me know if you want further details.


  • @peterbriers: Most excellent! I've already pushed a function that should do the trick. It is Wi3::inst()->unixpath($path) but I have not tested it... Will look into it tomorrow!

    @nanodocument: It should work, yes, but let me test that for you... :) edit: it works! The only thing is to place the .htaccess that you usually place in the root into another folder, and point to the proper vhost. Like this

    RewriteEngine On
    RewriteRule (.*) ../wi3/vhosts/%{HTTP_HOST}/httpdocs/$1 [E=REDIRECTED:TRUE,L]

    Note that it takes %{HTTP_HOST} as a parameter, so that if you visit it will work out of the box, but if you visit http://localhost/ it will probably not, unless you copy the '' vhost folder and name it 'localhost'....!

    Hope that works!

  • This is my folder structure:

     - tests/
       - wi3/
         - .htaccess
         - app/
         - vhosts/
         - sites/
         - docs/
         - kohana/

    Here is my .htacess

    # Turn on URL rewriting
    RewriteEngine On
    # Installation directory
    RewriteBase /tests/wi3/
    RewriteCond %{SERVER_NAME} ^$ [NC]
    RewriteRule (.*) vhosts/%{HTTP_HOST}/httpdocs/$1/ [E=REDIRECTED:TRUE,L] 

    Notice that my configuration is at the 2nd level from the root. Usually kohana is fine with that as long as I make the RewriteBase pointing to the right location.

    When I go to I get: The requested URL /tests/wi3 was not found on this server.

    However, If I moved the whole thing to www and change the RewriteBase to RewriteBase /wi3/ I know get the error reported by peter. Changing the line from $componentsdir = substr(FILE,0,strrpos(FILE, "/"))."/components/"; to $componentsdir = substr(FILE,0,strrpos(FILE, DIRECTORY_SEPARATOR))."/components/"; makes it work.

    Now we are back in track. Then I did the _wi3controllers/setup/ thing (which should be preferable be done via an installer). Everything went fine.

    Then I went to superadminarea and tried to create a site, the problem now is that it requires the user to be able to "create databases", I will be hesitant to have the root account in the settings so the user account I created didn't have the privileges to create databases, I changed that and tried again (remember that first time it failed due to privileges).

    The second time I tried, the error I got I guess was because I tried to create an existing site (entry was already on db). So I deleted the entry and retried.

    Final attempt, db user has privileges, no entries in db, I try to create a site and then it complains about creating a table (DB was created).

    Sorry, I gave up.

    My conclusions:

    Too complicated to setup
    Non-Kohana Coding standards
    DB user needs privileges for creating DBs, might not be available for everybody
    pointing to localhost or does not work transparently
    Only in dutch ;)
    Does not work in subfolders over 2 levels
    Windows not fully supported

    I wish I can see your HTML5 editing part.


  • So I've added a small picture that explains how the routing works in Wi3 at https://github.com/fabricasapiens/Wi3/blob/master/docs/routing.png .

    Also, I've edited the readme to make it clearer that with the standard setup, http://localhost will not work, but will, and that it is easy to change the root .htaccess to make wi3 work with localhost or any other host you'd like.

  • @ Nanodocumet: very sorry to hear that... It has to do with our different setups somehow... I've tried the exact same thing as you (2 levels deep) and it worked fine.

    With regard to the DB issues, yes you will need to give root privileges, at least when the site is created. You could give 'normal' privileges after that if you wanted... But I agree that that is not very user friendly. On the other hand, just giving a bunch of SQL statements (which is the only alternative I guess) is not very friendly either... It should however check if it has the rights to create a site, and if not, give a set of SQL statements so that the user can do it manually.

    What error did you get when the table-creation failed?

    Your other points one by one:

    1. Setup seems more complex than I thought. I've an instance working within 1 minute, but I must admit that was not on Windows, nor with something else than a Apache2+PHP5.3+Mysql5 setup. Does your setup differ?
    2. I tried to follow Kohana standards whereever possible. Where did you encounter that it was not coded that way?
    3. True.
    4. Yup, cleared that up in the readme (hopefully)
    5. ;)
    6. It does, at least here...
    7. It should be right now.

    If you want to see the CMS working (with a very ugly template that is), go to http://fabricasapiens.nl/testsite/adminarea and login with admin/admin (need HTML5 capable browser for the adminarea). The resulting site is to be found at http://fabricasapiens.nl/testsite.

    Could you help me with feedback while I get the major issues fixed? I really want this thing to work flawlessly for everybody on all platforms!

  • On the other hand, just giving a bunch of SQL statements (which is the only alternative I guess)

    I haven't looked at your code yet, so I apologize if I am missing something. Couldn't you simply allow the admin to input the name of an already created database, which you can then use? Similar to how Wordpress handles the install?

  • @slacker: I use an already created DB for the 'primary' database, that holds the meta-info about all the sites. However, for every individual site, the CMS will create a new database for portability reasons. But yes, it should be possible for the setup to use an existing DB... So that if the siteDB already exists, use that one.

    And now that I'm thinking of it: The DB config for an individual site can then be configured to any DB one would like... See https://github.com/fabricasapiens/Wi3/blob/master/sites/demosite/config/sitedatabase.php

    @nanodocumet I think this is also your problem...! Stupid of me to forget about the individual site-DB-config... If you set the settings in the sites/demosite/config/sitedatabase.php right, does it work??

    Thanks slacker, for bringing this to my attention...!

  • My point 2)

    The line $componentsdir = substr(FILE,0,strrpos(FILE, "/"))."/components/"; is more readable and more Kohanish using $components_directory = substr(FILE,0,strrpos(FILE, "/"))."/components/"; and I see a lot of concatenated variables (eg, componentname, componentpath, etc)

    The problem I had was that the file sites/demosite/config/sitedatabase.php already existed and had hard-coded values for username and password. I changed them accordingly and now I get:

    Table 'eenwebsitemaken_demosite.site_user_tokens' doesn't exist [ DELETE FROM `site_user_tokens` WHERE `expires` < 1301604355 ]

    The table indeed does not exist in the db (but db does)

    My last attempt was to "delete" the demosite folder and then re-create the site (I deleted the database and the entry in the sites table). Unfortunately the error now is file not found ...sites/demosite/config/sitedatabase.php.

    Final remarks

    1) username/password hard-coded for db is not so good.

    2) creating a site without creating the necessary skeleton for the site is not so good. If I don't call my site demosite, nothing works (an even demosite does not work because of #1). I tried creating a site "test" and failed too.

    3) db prefix, I see that you name the db with a prefix of eenwebsitemaken_ however, be aware that not everybody is in control of their dbs, some hosting company add a prefix to your dbs, thus, you probably will get errors there too.

    4) Sorry, I find the CMS so far away from Kohana itself. To me is a little bit over engineered. A CMS should be mostly "plug and play", not seeing here.



  • I guess you're correct about the conatenation: Kohana uses underscores to separate entities from subentities, which holds for 'components' and 'directory of components'. But I must admit this is not a priority for me if I work in local scope. Bad habits eh.

    You're absolutely right about how the setup is annoying when it doesn't go right the first time. What you 'should' have done (but still not logical, I do need to fix the setup process) is to leave the demosite folder intact (with the right sitedatabase config), and remove the sitedatabase itself. If you then create the demosite in superadmin, the site db will get properly created and it should work.

    I'm aware of the DB issues: what I will do is let users decide in which DB they want to store both the global stuff and the site specific elements. If that DB does not exist, it will try to create it, and if that fails, it will present a notice with SQL commands and explanation how the user can do it manually.

    Basically the setup is the main thing I will be working on in the near future. It should indeed be plug&play. I do however not think that this brings it 'closer' to Kohana. It just makes it easier for users to install the CMS.

    The good thing is that the CMS is only Alpha software, so it can be improved substantially before beta or even final release... Thanks for your feedback! :)

  • Hi all,

    I've created a much smoother setup now...! A small step for cmskind, but a giant leap for the cms ;-)

    The readme has been updated to reflect the changes, and if any of you is willing to test the new setup out, that would be much appreciated!


    Edit: On another note: we have a new logo now ;)

    Wi3 logo

  • Hi, It's possible to show some screenshots from admin? thanks

  • Sure,

    I will get you some screenshots or a video some day next week!

  • I've downloaded this and installed on my local server, I get an error on the index file

    "ReflectionException [ -1 ]: Class controller_welcome does not exist"

    I've tried replacing the dynamic base_url defined in bootstrap.php to simply '/' but I get the same error

    Also I get a blank page for the /setup/ (although it is loading the setup class as I tested with some echoes)

    It would be great if I could get this working to check it out, but really what I want to know is, is it still being developed and are there any plans to get it working in KO3.3?

  • Hi arumdev,

    The first step is to go to the /setup/ page. If that one already fails, that's a major bug, because all it does really is just loading this file https://github.com/fabricasapiens/Wi3/blob/master/setup/index.php and that shouldn't go wrong. Can you dig in there a little deeper, and file a bug report?

    The CMS is developed at times, but there are no concrete plans for new features or integration with KO3.3. If you want anything reliable, then I would choose something else. If you want HTML5 editing possibilities, I would look at the contenteditable=true attribute and how it works in Wi3, and try to integrate that with your existing CMS.

Howdy, Stranger!

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

In this Discussion