I see there’s still no reply from devs on this (maybe it’s an elaborate one) so I advance my proposal.
I anticipate that my suggested approach needs a core change because I need an editedon field in elements’ db tables, so that creating/updating an element should also fill that field in the database (I need to know WHEN an element has been created/updated).
That said, it could be feasible to create a plugin, running e.g. OnParseDocument and OnManagerAuthentication (or something like that), that does some synch work between an ad-hoc Structure in the FileSystem (let me call this the "sfs"), and the modx database.
It should retrieve:
- the update timestamps of the elements from the db
- the update timestamps of the elements from the sfs
Then it will compare them, and take action accordingly: the rule is to automatically create/update the freshest elements; i.e. if it finds that chunk "whatever1" in db has a timestamp greater than the chunk "whatever1" in sfs, it must update the chunk file in the sfs. Otherwise, the reverse.
Similarly, if it finds that snippet "whatever2" exists in sfs but does not exist in db, it must create the snippet in the db according to the data it will be able to read from the "whatever2" snippet file on the sfs.
Filenames in the sfs have not to be the same of those in db, because the "real" names, as long as other stuff, has to be all contained in the file contents. Of course, as a convention, it will be convenient to assign in the sfs filenames at least similar to the corresponding "real" ones, just to recognize them easily when looking into the sfs folders.
As a convention, elements will be only deleted from sfs (not from manager UI), so that the plugin knows that if it finds e.g. template "whatever3" in db but not in sfs, it means it must DELETE it from the database; while if it finds e.g. tv "whatever4" in sfs but not in db, it means it must CREATE it in the database. This approach assumes that the main development cycle is done through the sfs (with beloved IDE, version control and so on), but apart from the delete convention just declared, there’s no problem in using both the sfs and the manager UI, interchangeably, as long as timestamps are there to let the plugin know what’s new and what’s not.
The "sfs" I’m speaking of is something like this on the filesystem:
elements
chunks
chunk1.html
chunk2.html
...
snippets
snippet1.php
snippet2.php
snippet3.php
...
...
(note the file extensions for proper syntax highlighting in the IDE)
If you open e.g. chunk1.html in the text editor, you find a data format like something that the plugin should be able to parse:
<!--
[comment]
This text won't go into the database. It's just a comment visible in this file on the filesystem.
So here I am writing some stuff I have to remember related to this chunk that I don't want those others with access to the manager UI care to read.
First, this chunk has been developed just for test purpose, but it could also be used to..... yadda yadda.....
[attributes]
name = "chunk 1"
description = "just a test chunk"
category = "my chunks"
clear_cache_on_save = true
[properties]
...
...
-->
<div id="spf_response">
<h3>[[+spf-thank-you]]</h3>
[[+spf-came-from]]
[[+spf-back]]
</div>
The create/update actions on modx db should be taken by using directly the scripts in:
core\model\modx\processors\element
The plugin of course should create that kind of files in the sfs when it needs to create or update a fresh element found in the database.
This plugin could be active on development and on production environment, but on production the behaviour should inhibit the synch from db to sfs, allowing only from sfs to db. This way, the synching between development server and production server could be done by updating the sfs from development to production, and multiple development servers could be managed with version control on the sfs stuff.
What do you think about this? Am I missing something? (maybe)
☆ A M B ☆
MODX Staff