This is a basic dynamic page loader package.
It allows you to implement a basic dynamic page solution with the actual website page contents being held in a database table.
The package can be found on github https://github.com/Phil-F/Fuel-DbPage
Phil.
Hi Wanwizard,
I am sorry but I don't understand what you are trying to convey here.
If you used a route with (:any) everything would be thrown at DbPage which is not what you want.
If you mean HMVC calls then they should work as normal unless they are not found then DbPage will be launched and a 404 displayed.
This is only called when a 404 is actioned by Fuel. It doesn't have anything to do with routing apart from that.
If you have the url http://www.mysite.com/welcome and you actually have a controller called Controller_Welcome then that controller will be used by Fuel.
If you have the url http://www.mysite.com/about which has no controller and therefore can't be found then Fuel will throw a 404 which will then launch DbPage. The package then searches the database table for a record with the title about.
If the about record is found it loads the various variables and displays the html page else it continues on and looks for a database record with 404 in the title and displays that along with setting the response to 404.
It is a very simple html storage and display mechanism.
Thats it thats all it does.
Phil.
Hmm...
Don't know what happened here. There was a thread where someone asked for solutions like this, and I replied that there are several ways of approaching this issue, and that I use a generic front controller to which all requests go, and which deals with the results internally.
The TS replied he would look at that approach, to which you replied to have a look at DBPage.
My reply was meant as a warning to that statement, as there is big difference to what DBPage does, and what my front controller does.
For some reason my answer ended up here. Must have been drunk or so...
You may want to store the pages as a tree in the database.
I'd recommend using the MPTT algorithm which I can help with if need be.
This means that you can add 'move' functionality if you wanted...
Hi Rob,
I was going to look at using the nestedsets package but just haven't had time.
I was also going to look at putting in to a controller of it's own and use route to control it but again haven't had time.
Finding time for my side projects is just not happening at the moment
Feel free to fork it and show me what you come up with though
I wanted to keep it as simple as possible so people could use it as a learning tool for Fuel but there are a few people using it now so maybe I need to make it a bit more of a serious project.
Cheers,
Phil.
Hi all,
There has been a little confusion over default routes so lets clear it up now
The ONLY route required by this package is really the _404_ route as that is how it works by catching the 404 and seeing if there is a page in the database table else continue to throw a 404 Page not found.
All other routes will work as normal you can add other controllers and modules in the normal way.
Phil.
I like this direction, here's a consideration... you could create a base controller that should be inherited... then alter the router function to use your class... Could make implementation automatic.
New features added to manage the pages.
#Features
* Store website page contents in a database for easy management
* Automatically installs
* Load page data with one call
* Add a new page by passing an array
* Add a new page by setting the class variables
* Update a page by setting the class variables and passing the page id
* Update a page by passing the page id and an array
* Delete a page by passing the page id
* Delete a page by passing the page name
The danger in this is that if your controllers that are mapped to your database routes will become accessable via module/controller/index as well, and that might not be desireable in all cases, you might want to hide the real paths, and only map via the database.
In that case it's better to use an (:any) route to capture the requests, instead of the _404_.