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 ext.radiantcms.org.
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 ext.radiantcms.org,
but not until it is more thoroughly tested.
Having run:
file_system:save:layouts
you should have used:
file_system:load:layouts
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:
http://github.com/nelstrom/radiant-file-system-extension/tree/master/lib/file_system/model.rb#L50-51
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
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
