Search

Just had a thought regarding Pages, and a rationale for storing these as physical PHP files rather than rows in sym_pages.

When projects go live we maintain separate Staging and Production servers. If there is a second phase of a project, we will make the updates to Staging and then push to Production when approved. A database migration/ensemble isn;t appropriate, since the production site will have production data (members, comments etc.). One of the most time consuming tasks is re-building Pages on the production server. A developer must use the Symphony UI to create a page, copy/paste the URL Parameters and select Events/Data Sources.

My suggestion is to store a page as a physical PHP file. The XSLT still remains as a .xsl file, but the configuration of a page becomes a file much like the anatomy of a Data Source or Event. Why?

  • it becomes more MVC-like. The page PHP file still isn’t strictly a Controller, but is moreso
  • Pages become instantly transferable between sites and can be migrated using FTP
  • similarly Pages can be added to source control
  • the Symphony database becomes purely about the data and not the site/URL structure
  • Extensions could potentially bundle Pages as well (as they can bundle DS and Events in data-sources and events folders). This would mean an Extension would essentially replace an Ensemble — a forum extension could provide the DS and Events required, but also come with the pages with these Components already attached
  • no database requests to look up a page — the current naming convention used to name the XSL files would be equally applicable

Additionally the page PHP file could be made more “controller” like by providing a trigger() method into which custom code could be placed. Instead of using an Event, code could be injected directly into the page itself.

The “Navigation” Data Source type would need to hook into some form of Page Manager which (like the DS Manager) builds a list of page PHP files in memory. Since they’re just objects I would think this would have a very low overhead — less than querying the database?

Migrating to such a system would be backwards compatible (or at least, easily upgradable). An update script would need to iterate over sym_pages, create the PHP files, and remove the pages table.

Anyway, just a thought.

I too have found this problem very irritating. I support a change like this.

I agree with this as well although a change like this would be a lot more work than meets the eye I think nickdunn. By removing the pages table I think you also remove all of the relational tools for existing events, etc for these pages ( I’m assuming as I haven’t had enough time to really delve into the complete mechanics of symphony ).

By moving these pages to actual files it would create a new level of complexity that could present a lot of problems. People won’t want to have to edit and create these “page” files as opposed to the current method. The ease of use of setting up a site is then eliminated. Then you have the problem of tracking custom changes to these pages. If you make a custom change to a page how will the admin center (created to handle generating these pages to allow for the ease of use) recognize those changes and work around them?

This can be accomplished but would be a large undertaking. With the next version of symphony right around the corner ( hoping ) let’s try and not give Allen another reason to push development back another year… :)

hehe

With the next version of symphony right around the corner

If you are referring to Symphony 3, I imagine that corner is very big. Good points nonetheless. Let’s see what Alastair has to say.

I don’t see it adding any complexity. The interface would be identical only instead of creating a row in sym_pages a PHP file is created. The editor would remain the same.

I’m merely suggesting that the storage of the page meta data (title, handle, its events/DS) are stored in a PHP file like a DS rather than a database table. It would allow for direct editing if desired, but the implementation to the end user would be identical.

The structure of sym_pages is very basic:

  • id
  • parent (id)
  • title (text)
  • handle (text)
  • path (text)
  • params (text)
  • data_sources (text, comma separated list of handles)
  • events (text, comma separated list of handles)
  • sort_order (int)

Therefore data_sources and events suits an array nicely.

The way I read your original post is having the pages being standalone classes essentially. With that thought I could see the benefits of having them as files. If just the meta data is stored in a file, kind of like a config file, I don’t see the benefits anymore. I may be off base, just trying to understand what you are suggesting.

I like the idea, but I wonder about using PHP files to store page configuration. I can see the benefit of being able to easily extend the pages with custom PHP. If this were to be implemented, I’d rather the page configuration files be XML. They could point to external PHP files, such as events and data sources, as well as extensions.

Take this one step further and use the Section Schemas extension to configure an XML file (or an XML file for each section) that stores the complete database structure for sections and custom fields.

Each data source could also be configured by parsing an XML file for each.

Then, use an extension to import data for page configuration, for sections and custom fields, and for data sources into the database. As much as I love the Symphony interface for building as I go, there’s nothing better than working on files in your favourite text editor (Coda) and clicking the publish button to FTP. It’s just so much more efficient when working with several files at once.

I think this could potentially get us closer to an XML and XSLT only workflow. I would like to see static XML data sources as XML files in a data directory in the workspace, which would get pulled into the ?debug XML just like XSL files.

This is the direction the guys seem to be working towards with the concept for Symphony 3; by decoupling the data structure from the database structure (schema-less database?).

I did consider having a page as an XML file. It makes sense from an overall point of view as “XML is great because you can define anything” but from a practical point of view PHP seemed a better choice. XML would require an additional step of parsing the DOM and building a page in memory — with a PHP file you simple instantiate the object (as you do with a DS or event).

I don’t want to focus so much on the “custom PHP trigger()” part. It was more of an afterthought. I’d rather focus on the other potential benefits that this change would provide:

  • a page becomes instantly migrateable by FTP
  • they can be version controlled through SVN, Git etc.
  • Extensions could also include Pages (perhaps the most powerful of the lot)

Here’s a rough example. I’m no PHP developer, it’s just an idea:

<?php

    Class pageHome extends PageController {

        public static function about(){
            return array(
                'title' => 'Home page',
                'handle' => 'home',
                'author' => array(
                    'name' => 'Nick Dunn',
                    'website' => 'http://nick-dunn.co.uk',
                    'email' => 'nick@nick-dunn.co.uk'),
                );  
        }   

        public $events = array(
            'login-info',
            'save-article'
        );

        public $data_sources = array(
            'articles',
            'latest-article',
            'navigation'
        );

        public $sort_order = 10;

        public static function allowEditorToParse(){
            return true;
        }

        public function load(){         
            $this->render();
        }   

    }

?>

As far as potential benefits go, I’d welcome the changes. Manually modifying your proposed PHP file wouldn’t be too arduous.

I agree, I would enjoy a setup like that as well, but providing those classes as an alternative to the current configuration goes back to the point that I made before: How do you keep the current tools in place while allowing the end user to manipulate that php file? I want to make sure you don’t think I am trying to down play this idea but instead pointing out a question I’ve had to deal with myself with my own framework.

I have a framework that I wrote that I’ve used for years for several very large projects and I’ve borrowed a lot of concepts from symphony. Although I do this very thing instead of having all of my page configurations in a database. My pages are php classes that are triggered based on url schemas set in a “driver” for the specific application being run. I wanted to create some tools to manage these “pages” within the framework admin center and it proved to be useless once I made any significant changes to the page. I’m sure that the symphony team can come up with a way to “work around” those changes but like I said in my original post, it adds a huge layer of complexity. You also lose all the advantages of being able to initiate and pull the information for pages and the relationships with SQL (however this could be counter-acted by simply keeping a record in the sym_pages table for each of these classes.) Which brings up an interesting point.

What if you had an override ability. Symphony would work the way it does now but for those of us who want this type of functionality you could set a flag to generate this class and have it override the normal functionality of symphony to use this class instead. I think this would be the best of both worlds because the code to instantiate these classes now is contained in one area (where the pages are generated now) and you wouldn’t have to create a way to manage these classes within the admin center because now it’s an “opt-in” feature.

I like the idea nickdunn, just playing Devil’s Advocate and pointing out the downside of going that route as I’ve already walked down that path with projects of my own.

How do you keep the current tools in place while allowing the end user to manipulate that php file?

In precisely the same way as DS and Events work (i.e. you don’t). If you want to customise the PHP file yourself, remove the allowEditorToParse function and it becomes a custom component, uneditable by Symphony’s GUI. I don’t want to get bogged down in the developer customisation of the PHP since it’s not a rationale to justify moving to flat files, more a possible beneficial side effect.

You also lose all the advantages of being able to initiate and pull the information for pages and the relationships with SQL

True. At the moment the “parent” page is stored as an ID in the page record. However the URL hierarchy can actually be established by parsing the filenames. The existing page XSLT files follow a strict convention (handles with underscores and hyphens) such that one can deduce the parent/page relationship directly from the file name.

however this could be counter-acted by simply keeping a record in the sym_pages table for each of these classes

Indeed, but this begins to negate moving over to flat files altogether. The main rationale is the ability to move pages between builds using FTP, bypassing references in the database entirely.

I don’t see it affecting the developer user-flow in any way, shape or form. The Page editor in Symphony would just create/edit PHP files rather than create/edit MySQL rows. This change would be completely invisible to a developer, only it would provide the option to tinker with Pages if they so wished (just as every so often we need to modify a Data Source manually to provide some additional functionality, and so making it un-editable by the Data Source editor).

Maybe, instead of adding PHP files, it would be better to simply add all information to XSLT file, as a comment? Whenever administration page with Page listing is visited it would compare dates of files with date stored in database. If file is newer than data in database, comment would be parsed and information in database updated.

That way it would be possible to move Pages through FTP, and one visit on Page listing would update information in database.

Such functionality can be implemented through extension, so it could stay optional :).

That’s a fair idea. It solves the FTP problem.

I’d be interested to hear the Symphony teams thoughts. I wonder what the initial rationale was for storing Pages in the database but Events and Data Sources as PHP classes. I personally like the idea of de-coupling the structure of the site from the database — leaving the database to store the site “data”, and the site itself residing on the file system.

It leans more towards the Ruby on Rails idea of convention over configuration. Symphony already uses this concept heavily — by using consistent naming conventions you can imply logic that the application interprets (such as the way content pages are constructed for Extensions). To my eyes it’s an obvious evolution to apply exactly the same concept used for Data Sources and Events, to site Pages.

In doing so it’s a more MVC approach. The page controller (not strictly a Controller in the MVC sense, but more of a render controller) becomes a tangible file, generated from a blueprint. A Page could then be said to consist of two physical files — its controller (PHP) and its view (XSLT). Both have the same file name (although .php and .xsl) in two separate workspace directories.

One of the biggest benefits (besides FTP-able and source-controllable Pages) would be the ability for an Extension to provide front-end pages. The line between an Extension and an Ensemble would blur slightly, but it would mean that one could drop a piece of front-end functionality (such as a login system, forum, newsletter system) onto their site directly just with an Extension. The problems with an Ensemble is that a user needs to install it and pick it apart, to import the components into their existing site (as I understand it.)

Imagine a Members extension that not only provides the data sources and events to enable user management, but also the login, forgotten password and profile pages, out of the box. As a developer I wouldn’t need to create these pages myself and attach the appropriate data sources since they could be provided by the Extension.

My problem with that idea is that one “object” (Page) would have to be in two files. Every other “object” is a single file.

Storing data in XSLT looks “cleaner” to me.

Extensions can provide front-end pages already: they just need to create/copy/move XSLT file to workspace directory at install time, and remove it at uninstall time. Plus add info to database. Not as easy as calling one API function, but still easy enough to do :).

I guess my negative outlook on this is I didn’t realize there was an allowEditorToParse method within the DS and events. If this was the case then my arguments are negated.

:)

I think it’s a good idea Nick. I am still digesting, and will reply properly tomorrow.

If there’s nothing dynamic about the contents of these new configuration page files, please consider making them XML rather than raw PHP documents. The attraction of Symphony is XML/XSLT, not PHP.

If there’s nothing dynamic about the contents of these new configuration page files, please consider making them XML rather than raw PHP documents.

Fear not. That was one of my first thoughts. :)

If there’s nothing dynamic about the contents of these new configuration page files, please consider making them XML rather than raw PHP documents. The attraction of Symphony is XML/XSLT, not PHP.

You’d then have the overhead of loading an additional XML file from disk and parsing it for the sake of a few lines. If it was written in PHP you’d also have the benefits of using op caches and accelerators so that it might not even hit the disk.

If you’d like it to be XML then why not set them up as XML processing instructions inside the page XSLT file? XML processing instructions were made to pass data onto the application like that :-)

rwarrender

Hi!

can you try sometime? i love see some result for the test launch ok?

let me know.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details