Modxfs-php finally born

OK, following on from this thread http://modxcms.com/forums/index.php/topic,36703.msg240373.html#msg240373 I’ve finally finished the modxfs php port, details so far can be found on my site here http://bitez.hobby-site.com/index.php?id=95. Whwn I finish testing hopefully today/tomorrow I’ll post the code, RPM’s etc. This page also documents a workaround for MAC/Windows users who may need this.

OK, first cut is ready. The docs, zips of modxfs-php and the php-fuse module, a php-fuse module SRPM for RHEL/Centos/Fedora and two pre-built RPM’s one for Centos5 using PHP 5.2 and one for Fedora 11 64 bit are here [

http://bitez.hobby-site.com/index.php?id=63&relPath=projects/modxfs-php.

I’ve got a hitch with Centos5 PHP stock issue of 5.1.6, this may appear later, for now you need at least PHP 5.2

Please read the README and the INSTALL docs before testing.

Remember, testing only please. I don’t believe this utility was ever intended for production use, just as a dev tool, but still be aware that it almost certainly
still contains bugs that will lose content from your database if your not careful.(Or even if you are careful!)

Its targeted for evo but works on revo databases with the caveat that there are no modules so you won’t see these.

There’s also a doc outlining possible integration with subversion, so you can have versioned filesystem content that automatically reflects its updates into your database too.(Maybe a bit OTT but who knows!).

Ok, RPMs for stock Centos PHP 5.1.6 now done, in the C5php51 directory.

nice!

i guess that this is for evolution...

any chance to get it for revolution, too?
i would love it

ciao
a.l.e

Yes, at the mo it follows evo in the database table implementation, you can use it for revo but there are no ’modules’ etc. and it doesn’t use other revo tables like contexts for instance. My main area of development will be for revo rather than evo but I still need to do some work to get it solid for evo, then move it on.

This. Is. Awesome.

Setting up versioning is a great idea. Not over the top at all, have an enterprise client right now that might make use of something like that within the IT dept workflow -- fast, direct, versioned development to the dev install, push milestones to test in staging, then when vetted to production. Thanks to everyone involved, keeping a close eye on this!

Just to bump this slightly, I’ve now got a plan(sort of)to integrate the modxfs file system with SVN, but I need to try it, i.e. code it to see if it flies or not. I think we need to do this first so we can prove we can integrate this into a version control system. There are almost certainly some gotcha’s here. The integration with evo/revo and expansion of the existing functionality is a lot easier than integrating with SVN. I’ll start this next and see how we go.

OK, this seems to work now, we can integrate the modxfs mount point with SVN(or in fact any other VC system that keeps all of its own files in its own area, ie .hg for Mercurial, .git for Git etc.) The pics attached show SVN repo views, filesystem level views and DB views of the MODx db content on one of my test sites. Notice the .svn directory in the filesystem view, just like a normal working directory. I’ll post a tech note and the latest code for this as soon as I’ve written one and tidied the code up.

What this means is that we are now close to the following scenario :-
User A mounts the db using modxfs-php and checks out his latest content from SVN into it. This will reflect immediately into the DB
User A edits his content using editor/IDE of choice and tests his updates while going.
User A is now happy and commits his changes.
User B on another machine say, mounts the db using modxfs-php and checks out the latest content from SVN into it.
This will immediately sync his db with the last commit from User A(or any other revision for that matter).
Users C and D can do the same, a repo can serve as a central repository for many DB’s etc.

Still needs more work on some mechanics here and I need to beef up the setattr/getattr side, duplicates etc but I believe this is now doable

For people that have their /assets directory under vc control there’s no reason that I can see at the mo why the db mount point can’t be in here somewhere, then of course you could roll back/forward whole sites and sync the db also from revision to revision, this would be nice but were not quite there yet.

Nice! Keep it up, please.

OK, latest code modxfs-1.1.0.zip along with updated docs now posted in the project area of my site, links above.

We now need to implement full attribute handling, this will allow duplicated entries to be handled i.e. at the mo in resources for example we have
’resource.html’ at the filesystem level where ’resource’ is the pagetitle from the db. Of course the db can hold many resources with this pagetitle but with different id’s, so we need to implement this ’<pagetitle>-<id>.html’ once done we can extend this again to allow us to mount history databases as created by the Auditor module as ’<pagetitle>-<id>-<version>.html’, some people may wish to view the history database this way.

You could of course integrate into SVN, should you wish although keeping a versions of a versioning database may be a bit OTT.