Re: [Radiant] file_system extension (and other import/export tools)
1. There are a couple of other extensions that appear similar (Sean's Import/Export and and Istvan Hoka's Super Import Export come to mind). How is yours different? The file_system extension does not attempt to back up the entire database representation of your Radiant website, whereas the other two that you mentioned do. The main goal of the file_system extension is to make pages, snippets and layouts easily editable as files on your file system. This allows you to use your usual text editor, rather than having to do everything through the Radiant admin. It is most useful when you are designing (or redesigning/refactoring) a site. 2. If I use the file_system extension with other extensions (like, say, SnS) is it aware of these new models? Will it export them too? No, not out of the box. However, the file_system extension has been designed so that other extensions can ride along with the import/export process. For example, Sean Cribbs template_extension[1] adds his custom Template and PartType models, so that these are also saved to the file system. Naturally, this code belongs in the templates extension, rather than in the file_system extension, because you only want to back up Templates and PartTypes if you have that extension installed. I would be happy to work with you, Chris, in making SnS play along with the file_system extension. If you are looking to backup your website to the filesystem, I would say that the (super)import_export solutions are a better fit. These should capture all tables in your database as yaml files. (There is one possible exception, which I will detail below.)* I hope that this helps to clear up any confusion. Cheers, Drew * The import_export extension can back up all database tables whose name translates using the normal Rails conventions. e.g. pages (table) with Page (model), page_parts (table) with PagePart (model). In the Radiant core, there is just one model which breaks this convention: the config table corresponds to a Radiant::Config model. This is given special treatement in the import_export extension, to make sure that it is captured in the yaml file. If any other extensions include models whose name cannot be discerned from the corresponding table name, then they will not be backed up to the yaml file. [1]: http://github.com/seancribbs/radiant-templates-extension/tree/master ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] OT: Background colour
john wrote: The Z-Man has it backwards. If the user goes out of their way to set a custom background color the site should respect that, the same as with user selected fonts and css and whether images are shown and whether javascript is enabled and whether Flash and Java are available, etc. etc. and so on. As I understand it, the argument is that if you set the color attribute, you should set the background, too. Otherwise, user might pick the background to be the same as your color, thus making the content unreadable. So, its not only about the appearence. Sure, its a minor thing, but I belive there is some merit to it, however small it might seem. On the other hand, if Radiant never adopts this way of thinking, thats fine, too. It is only a minor thing, after all. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] OT: Background colour
My assertion was that anyone who has gone to the effort of changing the browsers background color is well prepared to deal with the mess they make if they choose black for instance, i.e. those same people are also likely to have user level css applied in addition to deal with when this happens. I think this just happens to be one of his pet issues. http://www.zeldman.com/2007/06/18/bgcolor-follies/ http://www.zeldman.com/2008/11/07/is-your-websites-underwear-showing/ On 2008/11/08, at 11:24, Saša Babić wrote: john wrote: The Z-Man has it backwards. If the user goes out of their way to set a custom background color the site should respect that, the same as with user selected fonts and css and whether images are shown and whether javascript is enabled and whether Flash and Java are available, etc. etc. and so on. As I understand it, the argument is that if you set the color attribute, you should set the background, too. Otherwise, user might pick the background to be the same as your color, thus making the content unreadable. So, its not only about the appearence. Sure, its a minor thing, but I belive there is some merit to it, however small it might seem. On the other hand, if Radiant never adopts this way of thinking, thats fine, too. It is only a minor thing, after all. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] OT: Background colour
On 2008/11/08, at 12:48, Sean Cribbs wrote:
I shouldn't need to say this, but Patches Are Welcome (tm).
http://github.com/johnmuhl/radiant/tree/valid_css
I guess valider-css might have been a more appropriate name. There
are still the 3 errors regarding browser specific css but those aren't
real errors just the validator complaining.
On 8-Nov-08, at 11:35 AM, Mohit Sindhwani wrote:
Actually, I am tempted to agree with Saša on this one - if *you* set
a foreground color, *you* should set a background color. A default
background should not apply if you override the foreground.
Of course you should and as pointed out, by Adam, below if you use a
validator you'll be immediately notified of your oversight.
On 2008/11/08, at 12:42, Adam van den Hoven wrote:
Its a common validation check (if an annoying one) for CSS
validators to report a warning if you set a foreground color without
setting a background color. In general, its best to set both at some
point. It eliminates ambiguity.
So the real complaint is that authors don't use (or respect)
validators, and that's a valid one.
A user who specifies there own style sheet (are they any?)
I use global and site specific stylesheets fairly regularly and if I set
html, body { background-color: black !important; color: black !
important }
there is nothing an author can do about. If you just set your Firefox
background color using about:config and don't specifically set the
text color you're probably not doing it to demonstrate any real life
user configuration.
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
