Using Fuel_posts class without expected fields?

is it possible to map legacy database fields to the ones expected by Fuel Posts?

Lets say I have an existing database with the fields:

products_title VARCHAR, 
online INT 1|0
changed INT 1|0

and looking at the program flow of Fuel_post, there are a lot of assumptions that fields like:



and it seems like I have to overwrite all kind of methods to get something out of the database and into the routes I defined in

$config['modules']['products'] = [
    // ...
    'pages' => [
        'base_uri' => 'products',
        'per_page' => 5,
        'vars' => [
            'foo' => 'bar'
        #'layout' => (!isset($_GET['json'])) ? 'main' : 'api_json',

        'list' => [
            'view'  => (!isset($_GET['json'])) ? '_posts/posts' : '_api/test',
            'route' => '([a-z]{2})/products'

I think there should be a much clearer hint on, that this is a very opinionated way of setting up pages and should only be approached if one just starts over with a new database table or is able to change an existing one to match Fuel Posts expectations. Is that fair to say?


  • You can create your own simple module that refers to whatever fields you want. It should be easy to set up a new simple module that uses an existing table and fields.

  • If you inherit from the Base_posts_model, you essentially are getting a boilerplate with some predefined assumptions. I would recommend creating a model that is a copy of that (but also inheriting fromBase_posts_model) and go through it to overwrite the defaults (e.g. filters, required field, boolean_fields, unique_fields, order_by_field, order_by_direction, slug_field properties and the form_fields method). After you make those changes then merge in any custom methods from that legacy table.

    So, in short, yes, it's an opinionated boilerplate, however, you don't necessarily need to change your table and should be able to overwrite the model with your specific legacy code.

  • Thanks for the confirmation!
    I think what throws me off the most is the fact that it's hard to find out which config variables have an effect and when or better why not at all.
    Once I'm deep into Fuel CMS it all makes more sense, but in the beginning it's a bit of a struggle... at least for me. But thanks to xdebug and Kint I find my way ^^

Sign In or Register to comment.