Ruby Forum Radiant CMS > File-based Snippets/Layouts with Support for Radiant Tags?

Will we ever see the light of day for this feature. I personally despise
editing code/indent-heavy layouts/snippets in Radiant. What are the
limitations that prevent this feature from being implemented?

Arik Jones wrote:
> Will we ever see the light of day for this feature. I personally despise
> editing code/indent-heavy layouts/snippets in Radiant. What are the
> limitations that prevent this feature from being implemented?
>   

Would it help you to use an external text editor of your choice for
editing the entry of a text box in Radiant?  I remember that there is a
Firefox extension that can open up an external text editor of your
choice.  I searched it up and found this:
http://lists.radiantcms.org/pipermail/radiant/2007-May/004928.html

Hope this helps.
Cheers,
Mohit.
8/25/2008 | 12:29 PM.

Sorry Mohit, but that really doesn't help. I think it's a fairly 
important feature to be able to modify Layout/Snippets outside of the 
web UI. Also, relying on one browser platform to get this done is quite 
silly and actually defeats the purpose of a text-editor. Eh... just a 
thought.

I seem to recall an extension for VIM that allowed you to edit stuff
in Radiant using VIM. You might give that a try. I can't imagine file-
based stuff making it into core though. Perhaps the closest we would
get to that would be an import/export feature.

--John

The file_system extension exists for this purpose. Check it out:

http://github.com/nelstrom/radiant-file-system-extension/tree/master

I should warn you that it is still under development, so if you do use
it, take care! I would appreciate feedback on any problems you
encounter.

Drew

Yes,

as I told in a previous post 
(http://www.ruby-forum.com/topic/163688#new) I'm actually using Andrew's 
extension to dump my Radiant layout for the following pourposes:

- backup & versioning:
via "rake file_system:save" I dump the layout onto the filesystem, than 
I make some html/css changes here and there, I git commit -a -m "New css 
layout bla, bla ...", and load the layout back into the DB via "rake 
file_system:load"

- port my Radiant layout to the separate Rails app layout, which I like 
to look and feel the same way:
smoothly cat & past some dumped html/css files between the two 
applications modifying destination partials files name, and app/views 
dir scructure accordingly

That's working fine for me until now. I'm using radiant-0.6.9 as a gem,
and the commit commit 625ba8e31b7ffe3d9ca50019cf20bf942b9290c3
Author: Andrew Neil <andrew.jr.neil@gmail.com>
Date:   Thu Jul 31 07:19:04 2008 +0100

thanks Andrew
lgs

Andrew Neil wrote:
> The file_system extension exists for this purpose. Check it out:
> 
> http://github.com/nelstrom/radiant-file-system-extension/tree/master
> 
> I should warn you that it is still under development, so if you do use
> it, take care! I would appreciate feedback on any problems you
> encounter.
> 
> Drew

Does this jive with the Styles N' Scripts extension? If so, I think 
you've solved a really large problem for me.

On 25 Aug 2008, at 14:13, Arik Jones wrote:

>> Drew
>
> Does this jive with the Styles N' Scripts extension? If so, I think
> you've solved a really large problem for me.

Not yet. That was the first question to be asked when I announced this
extension:

  http://www.ruby-forum.com/topic/152887#709163

so I can probably say it tops the list of desired features. Sean
answered the Q in the same thread.

Sean designed the extension for the Redken site, which included a
couple of additional models. I have basically taken Sean's extension
and stripped out all of the Redken specific functionality. If you look
at the extension as it was when I first checked it in to github:

  http://github.com/nelstrom/radiant-file-system-extension/commit/cf20284c13f3a43d00408086e628c2c13337380c

you can get an idea for what Sean means when he says "you can just
create an appropriately named module". In particular, I draw your
attention to the files:

  /lib/file_system/model/part_type_extensions.rb
  /lib/file_system/model/template_extensions.rb

These files describe the save and load functionality for PartType and
Template models. I have discarded them, because the corresponding
models were custom built for Redken. On the other hand, I have
maintained the page_extensions.rb file, because the Page model is part
of Radiant core.

I think it would be quite straightforward to add the functionality in
a similar fashion for 'text-assets' such as stylesheets and javascript
files. If I understand Sean's design correctly, I think his intention
was that extension authors could make their custom models play with
the FileSystem extension by adding modules such as (using SnS as an
example):

  /lib/file_system/model/stylesheet_extensions.rb
  /lib/file_system/model/javascript_extensions.rb

These modules would be added to the SnS extension itself, rather than
in the FileSystem extension. If you had SnS installed without
FileSystem extension these modules would do nothing, but if you had
both extensions installed, then FS would pick up the extra
functionality provided by those modules in the SnS extension. (It
might be necessary to specify the load order of file_system extension
before the others)

I'm offering these pointers to help anyone get started on this who
wants it. I have my plate full just now (and a vacation as of next
week) so I won't be able to have a go at this myself for at least a
month.

Cheers,
Drew

> These modules would be added to the SnS extension itself, rather than 
> in the FileSystem extension. If you had SnS installed without 
> FileSystem extension these modules would do nothing, but if you had 
> both extensions installed, then FS would pick up the extra 
> functionality provided by those modules in the SnS extension. (It 
> might be necessary to specify the load order of file_system extension 
> before the others)

The only thing extra you would need to do is to test for the existence
of the FileSystemExtension and then add your models to its list:

if defined?(FileSystemExtension)
  FileSystem::MODELS << 'Stylesheet' << 'Javascript'
end

Then the extension will pick up those models, add the basic
functionality and attempt to add their specialized modules as well.

The extension is very helpful when you are working on a big site, or one
that you want to manipulate significantly offline.  I'd call the support
for Pages shaky at best, and I'd still recommend manipulating those in
the regular interface.  However, the other models -- snippets, layouts
-- are very simple and easy to manipulate in the filesystem.

Thanks, Drew, for offering to maintain this extension!

Sean

> I'd call the support for Pages shaky at best, and I'd still  
> recommend manipulating those in the regular interface.

Agreed. The Page model is far more complex than Snippets and Layouts,
because it has_many PageParts, and acts_as_tree. I'm road testing the
extension myself at the moment, and have noted a several bugs. I've
already fixed a few of them, but others keep cropping up. I hope to
announce progress in a separate thread soon.

> Thanks, Drew, for offering to maintain this extension!

It's a pleasure. I really needed it to help me refactor a large site
which has been getting out of hand. With the file_system extension, my
workflow has become so much more manageable. It is a huge relief!

Cheers,
Drew

I just had a crazy idea.

I'm looking for a way for users to have a "draft" version of the site.
 When it's ready, they click a button and the pages/snippets/layouts
that are published get transferred over to the new site.

What if:

When they click "Publish Site":
  * test site does a "rake file_system:save" to save the test db stuff
to the file system
  * files are checked into git
  * production site does a checkout
  * production site does a "rake file_system:load" to load the files 
into the db

And Tada.  You have a simple, version controlled site where people can
preview their work.

Joe

On Mon, Aug 25, 2008 at 1:40 AM, Andrew Neil

@Joe Van Dyk

Whoa. Take it easy there mister. We're not trying to change the world 
here! lol.

Back in December 2007 I wrote a quickie extension for someone to have
two separate sites, one being preview and one being live.  In the end,
we decided it would be easiest to copy a SQLite3 database file from the
preview site to the live site (luckily on the same box).  No version
control, but it was an easy way to keep them separated.

BTW, you could achieve what you mention also with the import/export
extension (which I added a few fixes to the other day).  It would not be
easily readable (it's all YAML), but it can maintain all the original
data, including data that isn't expressly written in the file_system 
ext.

Sean

I wrote an extension that is being used in production that does
something very similar.  We have a staging environment and a
production environment.  The production environment is read-only.  The
users make all their changes on the staging environment.  When they
are ready to migrate the changes to production, they go to a Staging
tab on the staging environment and click a button.  Behind the scenes,
the radiant content is copied from the staging environment to the
production.  It can copy the data between two environments on the same
machine or two environments on different machines (via ssh gem) simply
by changing a flag in the config file.  Because the extension uses
mysqldump, right now it is limited to only mysql databases.

So far, the client has tentatively been agreeable to me open-sourcing
this extension.  Two things have kept me from pursuing that, namely
time constraints and my thinking that this might not be useful to
anyone else.  If others think this extension might be useful to them,
I can move it up my priority list.

Jamey

It just so happens that I was playing around with getting the
file_system extension to work with SNS when I came across a nasty
conflict. It seems that SNS uses the attribute "filename" instead of
name. Because the file_system extension uses this as well, it leads to
all sorts of nasty issues.

If you change the attribute to 'name' (or anything else for that
matter), then everything works nicely. But I can't figure out how to
reset the filename attribute in the class extension and keep the whole
thing working. Maybe Chris will be kind enough to change the filename
attribute in sns or someone else has an idea. It would be great to get
these two plugins working together!

Keith

On Aug 25, 2008, at 4:35 PM, Sean Cribbs wrote:

>>
> list:
>
> if defined?(FileSystemExtension)
> FileSystem::MODELS << 'Stylesheet' << 'Javascript'
> end
>

I just tried this out with my hacked version of SNS (with "name"
instead of "filename") and for the most part it works. The only things
is, while the names of the models get loaded in the constant list, the
model extensions do not. If you manually add the Model names in the
file_system extension, then they do load (and strangely, if you
inspect the list, the added model names are there twice).

Again, odd, bu it is actually working and I can now export css and js
files from the SNS extension. Once I get this oddities cleaned up I
will try to fork it.

Keith Bingman

Oh, I forgot to mention that your extension must load before the
file_system extension for this to work:

config.extensions = [:all, :file_system]

-- should do the trick in config/environment.rb.

Sean

Hmm. Still giving me problems. It seems like the array is loading, but
e´the model extensions are not...

Keith