How to use com_content with Pages

[sakiss]

Hi

Seems like the Pages are a step towards improving the performance of the CMS. Though I am looking for a way to incorporate main functionalities of the cms into the pages, instead of bypassing them.

For example looking for way to integrate/convert articles into pages. Since the articles uses more than 1 db tables, the database collection does not seem to fit.

I am thinking to develop a plugin that will create a page (including the necessary vars in it's frontmatter), upon the article is saved.
Not sure if this the way to go.

Any idea is welcome!

[johanjanssens]

Hello Sakiss,

Happy to help you. The goal of Pages is not to bypass the functionalities of Joomla, Joomla is a great CMS and a lot of work has gone in to the content editing features over the years. With Pages I'm focussing mostly on data rendering either as html, or as json (webservices).

To create a leap forward in performance I needed to architect a very different approach to how data is retrieved and rendered then the component based approach Joomla uses today.

Basically Pages replaces the component based paradigm and architecture with a collection based paradigm and data driven architecture. The menu manager and frontend templating have been totally replaced.

I do want to make sure that Pages can very easily retrieve data from any existing Joomla extension. The default collections are indeed a bit limiting to do proper integrations with multi-database extensions. To solve that I'm working on an Extension API for Pages. More info can be found in following PR's:

• Extension API: Extension API #144
• Extension Packages: Extension packages #360

As part of the 0.22 release I'm working on 3 example extensions:

1. Joomla content:Joomla extension #363
2. K2: K2 extension #365
3. J2store: J2Store extension #377

All these extensions are working with Pages 0.19. You just need to copy the code into your /joomlatools-pages/extensions folder and you can get started with them. I did a lot of work on the Joomla extension over the weekend, a little recap you can find here: #541

Finally, as an example @waseemsadiq and myself have build https://www.agrea.ph with Pages, and we open sourced the code, you can find it on my Github: https://github.com/johanjanssens/agrea.ph It shows how to use the Joomla extension with Pages to render articles with Pages and manage them using the Joomla article editor.

If you have any further questions on this happy to help you.

[kbrookes]

@sakiss - what specific elements are you trying to utilise from com_content?

It's pretty straightforward to grab all the standard article 'bits' from the collection - title, intro, full text, category, author, published state, image, etc. Even custom fields are grabbable, although it's been fractionally more effort to do so until now. Johan's got some fancy new methods for grabbing those too.

[sakiss]

Thank you for the responses guys.

@johanjanssens The agrea.ph is indeed a helpful resource.

Questions:

Will the database queries (from the Pages extensions' model) executed every time a page is requested or the output is somehow cached and served from there?

I am coming from an OOP background and i am an advocate of the collections. Though my approach is a bit different in regards to collections and Joomla. In my apps, i am using the Joomla components' models as resource models (i.e. models that fetch raw data) and then do the object mapping and add the objects to a collection. The collections are agnostic to the persistent layer of the resource models (can be memory, database, filesystem) and load as long as the resource model returns data. This way the data fetching is completely abstracted from my collections.

I wonder if an approach like that would be helpful for the Pages, given that, to my understanding, pretty much the same database queries with the components' models are being required. Also Pages will be more portable and less code will have to be maintained. Just a hint. You know the bigger picture of that.

@kbrookes
Pretty much the basic data for the moment (title, text, metas, custom fields). But possibly will have to also load some category pages.

[johanjanssens]

Will the database queries (from the Pages extensions' model) executed every time a page is requested or the output is somehow cached and served from there?

They are executed every time, there is no data cache for the database model. Caching is happening in the dispatcher on a HTTP level, I'm caching the whole response (headers + body), similar to how caching in Apache works

The idea here is that the generation of a page can be slow, but the page should only be re-generated when the collection's data on the page changes. This works by generating a hash for a collection, if the hash changes for any of the collections used by a page the dispatcher knows that the page needs to be re-generated. There is a little bit more to all this, but that's the basics.

With that said, I have a data cache for the webservices collection. It wouldn't be too hard to add one for the database collection if you need one, the model behaviors make that very easy to do, there is however no real reason for optimising on that level by default, adding a data cache for the database would be more an improvement you would make for a specific use-case.

I wonder if an approach like that would be helpful for the Pages, given that, to my understanding, pretty much the same database queries with the components' models are being required. Also Pages will be more portable and less code will have to be maintained. Just a hint. You know the bigger picture of that.

This is how Pages works. The name collection could be a bit confusing here. I'm using this to make it simple to understand for none OO developers which is the target audience for Pages, collection vs item are easy to understand terms for everyone.

Under the hood Pages using an MVC architecture, where the model is responsible to retrieve raw data from a data source and transform that into entity objects. In DDD terms the entity is an aggregate object that uses a composite pattern, and implements a prototype pattern to construct new entities through a factory. On top of that entities are domain aware, they map themselves to their respective domain through their object identifiers.

Object mapping happens at the entity level. For example a Joomla article entity is mapped to a fields entity and a category entity

Entities, entity mapping, composites, domain identifiers etc etc are all abstracted through the collection. Everything a developer implementing Pages needs to know is how to create and use a collection, and the goal is that he shouldn't need to construct any classes or write php code to do that. It all happens through the frontmatter.

For more info how the MVC in pages came to be, some history and ideas behind it following talk I gave last year might be of interest: https://www.youtube.com/watch?v=srOb8VgEOmw

Hope that helps.

[kbrookes]

@sakiss so your questions area goes significantly above my head, but I'll show you a little of what I'm doing to give you an idea. For a recent, fairly simple site with a blog, I have the following directory structure that looks like this:

joomlatools-pages
-- pages
---- updates <-- collection folder
------ index.html.php <-- collection category display
------ update.html.php <-- collection individual article display

In the index.html.php I have this in my frontmatter:

collection:
    model: ext:joomla.model.articles
    state:
        published: 1
        category: 9
        sort: created
        order: desc

And some of the calls I make:

<h1><?= collection()->category->name; ?></h1>
<p><?= collection()->category->text; ?></p>

and:

<? foreach(collection() as $update): ?>
<div class="row style-square updates-item">
    <div class="col-12 col-sm-3 col-md-4 col-xl-3">
        <a href="<?= route(page('updates/update'), ['slug' => $update->slug]) ?>">
            <div class="image-box" style="background-image: url(<?= $update->image->url; ?>)">
                <div class="image-box__inner">
                    <img src="theme://images/brand/distilled-device.svg" class="w-100 h-100" />
                </div>
            </div>
        </a>
    </div>
    <div class="col-12 col-sm-9 col-md-8 col-xl-9 d-flex align-items-center">
        <div class="updates-item__copy">
            <h2><a href="<?= route(page('updates/update'), ['slug' => $update->slug]) ?>"><?= $update->title; ?></a></h2>
            <?= $update->excerpt; ?>
            <p><a class="btn btn-outline-primary" href="<?= route(page('updates/update'), ['slug' => $update->slug]) ?>">FIND OUT MORE</a></p>
        </div>
    </div>
</div>
<? endforeach; ?>

That handles my category view. In my article view, in update.html.php:

Frontmatter:

---
route: updates/[:slug]
layout:
    path: default
collection:
    extend: updates <-- re-use collection defined in updates/index.html
---

I'm using extend here to re-use the collection I have already defined. Extend uses the page path, since the collection is defined in a index.html the page path is simply updates Then I do some fun stuff like this for images and fields:

if( !empty( collection()->image ) ):    
    $articleImage = collection()->image->url;
endif;

$deviceBG = collection()->fields->get('image-alternate')->value;
$simpleCTA = collection()->fields->get('simple-cta-for-blog-posts')->value;
$ctaTitle =  collection()->fields->get('article-cta-title')->value;