Sorry I couldn't respond to this sooner. It has been a busy time for me lately.

I've been meaning to write to the list about file_system for a while now. I wrote to Drew and praised him for it and he let me know that it was Sean's invention. Cheers to both of you, nice work.

I played around with it in development to discover that if I created a single file for a snippet and then had it load to the DB, it would delete all others. I didn't read the documentation closely, so it was a simple mistake, but I expected it to be non-destructive unless I told it to be.

I'm curious about what others think of this. I would expect that when I tell it to load my files to the database, it would just load them, not destroy everything and then load them. I'd prefer that that be a rake argument.

I've pasted excerpts from my discussion with Jim at the bottom of this email. It goes into some detail as to why the database is destroyed when you run file_system:load (now file_system:to_db, see below...).

In brief: if you run file_system:save, you get a copy of every layout, snippet and page on your file system. If you delete one of these files, then run file_system:load, the corresponding record in the database will also be deleted. You can also create new snippet, layout or page_part files, and these too will be created in the database when you run file_system:load. Essentially, my aim was to make all CRUD functionality available through the file_system.

When I took the extension from Sean's hands, it didn't delete database records when you deleted their corresponding files. I found this to be quite a frustrating limitation. If I wanted to delete a file (most commonly a page part), I would have to do so through the Radiant admin. If I had made alterations to the file_system (FS) copy of the site, it was imperative that I loaded them back in to the database (DB) before I deleted the unnecessary page_part. Otherwise I would have changes made to the DB and FS versions, both of which I wanted to keep. This is a situation which can be avoided now that you can just delete a file, and know that it won't be resurrected on the DB next time you run file_system:load.

Jim's experience has revealed a fairly serious bug in the current implementation of the extension though: if you run file_system:load, it will delete all models which have not been saved to the FS. So if you ran file_system:save:layouts, you would have no pages or snippets on the FS, and they would all be deleted from the DB if you later ran file_system:load. (They would be safe, however, if you ran file_system:load:layouts).

This is not by design! It is an oversight on my part, and I intend to fix it.

Also, as I worked with it, I found it made more sense to be "file_system:to_db" and "file_system:to_files" because 'load' and 'save' just doesn't seem clear enough to me and I kept forgetting which was which.

I've just pulled in brianjlandau's changes, which were in turn forked from Jim Gay's branch. So the changes suggested above have now been incorporated: file_system:save is now file_system:to_files; file_system:load is now file_system:to_db.

And while I'm thinking of it, I would also just make it "radiant:to_files" and "radiant:to_db", but that matters less to me.

I see what you mean. In fact, the current "file_system:to_files" doesn't quite make sense. OK, it is in the name space of the file_system extension, but it reads as file-system-to-files which sounds like nonsense. Since you mentioned it, I've been thinking a neater convention for task names would be:

        rake db:to_files        (reads: database-to-files)
        rake fs:to_db           (reads: file-system-to-database)

I don't think it is critical to keep the file_system tasks within that namespace, because the extension just adds functionality to Radiant. It doesn't add any new tables to the db, or introduce new page types.

Any thoughts?


The following is an excerpt from an earlier discussion between myself and Jim Gay:

I forked your radiant-file-system-extension. That is great. You should add it to

I tested it out by saving my layouts (only) and then running file_system:load

My assumption was that it would only load that which existed in the file system, but instead it wiped out my pages.

Ouch. Sorry about that. As you can see, the extension is not entirely predictable. I do intend to add it to, but not until it is more thoroughly tested.

Having run:


you should have used:


to load from the FS back in to the DB. I have always run file_system:save and file_system:load, i.e. captured all layouts, pages and snippets at once, so I have not encountered the bug which you have just exposed. It won’t be obvious why running file_system:load deleted all your pages (and snippets too, I’ll wager), so let me explain.

When you run file_system:save, you should find a file corresponding to each layout and snippet, and a directory corresponding to each page, etc. (I won’t go on, as I’m sure you understand). If you make changes to any of these files, then run file_system:load, those changes should carry over into the database records corresponding to these files.

It is also possible to create new layout and snippet files directly on the file system (FS). When you run file_system:load, the system will generate new models for any files which do not correspond to existing DB records.

When I inherited this extension from Sean Cribbs, this was as far as he had got with CRUD – we had ‘C’ and ‘U’, but no ‘D’. I used the file_system extension in this state for a while, but found the lack of delete capability to be limiting. So I added it. And as you have just revealed, I made quite an oversight!

It should be possible to delete layout files, snippet files, page_part files, or page directories from the FS, and when you run file_system:load, the corresponding database records should also be deleted.

You fell foul of this for the following reason: you saved only layouts to the FS, but asked it to load all layouts, snippets and pages from the FS into the DB. When it found no pages on your FS, it assumed that you had deleted them (when in fact, they hadn’t been there at all), and so it deleted the corresponding records in the database.

Clearly, we need to provide a safety net to prevent users from doing this. I hadn’t considered this scenario, and it fairly complicates the issue. Thanks for bringing it up.

I got in there and realized that I need to do a lot of digging to get familiar enough to make that change

Here is the code which deals with deletion of layouts and snippets:

The code that deals with deleting pages is more complex, on account of has_many page_parts and acts_as_tree. I would like to brainstorm the radiant dev community on a best practice for deleting directories, bearing in mind that if subversion is being used for SCM, each directory could have a hidden .svn directory within. It gets messy, believe me. I shall write in greater depth about the issue in another email.

I thought I’d write to you and send that feature request… and of course to send kudos on a killer extension.

Well, I’m happy to maintain the extension, but the it is Sean who deserves the kudos for its design.

Radiant mailing list

Reply via email to