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 J. 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
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 N. [email protected]
Date: Thu Jul 31 07:19:04 2008 +0100
thanks Andrew
lgs
Andrew N. wrote:
The file_system extension exists for this purpose. Check it out:
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.
The file_system extension exists for this purpose. Check it out:
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
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
On 25 Aug 2008, at 14:13, Arik J. 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:
Layouts, snippets and site assets on the file system? - Radiant CMS - Ruby-Forum
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:
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
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
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 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 N.
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 C. 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 B.
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
Hmm. Still giving me problems. It seems like the array is loading, but
e´the model extensions are not…
Keith
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