Re: [Radiant] Re: What's the proper way to update an extension?
Ben, If you did a plain clone originally, run `git pull origin master`. Sean Ben Morrow wrote: Jim Gay wrote: Did you type that correctly? You're going from 0.7.12 to 0.7.10? (I'm not a user of this extension) Haha, you are correct, I accidentally swapped the version numbers. if you've already cloned the git repository for the extension, cd into that directory: cd vendor/extensions/gallery and do 'git pull' Tried this, and got "You asked me to pull without telling me which branch you want to merge with". Do I have to edit some settings, or should this be automatic? ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Problems with database_form
Update from my last post about the (1 of 2) arguments errors. When the form is submitted, the information is added to the database, but the page isn't redirected properly and there is nothing in the XML file generated on the "Form Response" pages. Just for reference, even the default form gives the same response. Radiant 0.6.7. Can anybody please give me some pointers on getting this thing to work? Thanks, Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Re: What's the proper way to update an extension?
Jim Gay wrote: > Did you type that correctly? You're going from 0.7.12 to 0.7.10? (I'm not a > user of this extension) Haha, you are correct, I accidentally swapped the version numbers. > if you've already cloned the git repository for the extension, cd into > that directory: > > cd vendor/extensions/gallery > > and do 'git pull' Tried this, and got "You asked me to pull without telling me which branch you want to merge with". Do I have to edit some settings, or should this be automatic? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Best way to refer to a stylesheet?
John and Catherine Allen wrote: Mohit, Thanks, yes: your excellent tutorial was my starting point. But I was having trouble because my Radiant site was in a subdomain. Now I know several ways to handle this. John Thanks John, I've noted your comment about the subdomain and will roll that in somewhere. By the way, the method in my tutorial should work even in a subdomain (not a directory but a subdomain). After all, the method there just uses basic Radiant for all the work. Let me know if you have the time again and can check what problem you're noticing. But I did notice that a few methods have been proposed. Cheers, Mohit. 6/10/2008 | 9:16 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] What's the proper way to update an extension?
Did you type that correctly? You're going from 0.7.12 to 0.7.10? (I'm not a user of this extension) if you've already cloned the git repository for the extension, cd into that directory: cd vendor/extensions/gallery and do 'git pull' On Jun 9, 2008, at 8:55 PM, Ben Morrow wrote: I know the Accents project is underway, but for now, how do I update my extensions? For example, I need to update Gallery from 0.7.12 to 0.7.10. I tried 'git clone [...]' into my 'vendor/extensions' directory, but I get an error saying that the "destination directory already exists". I'm sure its simple, but I'm still a newbie. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] What's the proper way to update an extension?
I know the Accents project is underway, but for now, how do I update my extensions? For example, I need to update Gallery from 0.7.12 to 0.7.10. I tried 'git clone [...]' into my 'vendor/extensions' directory, but I get an error saying that the "destination directory already exists". I'm sure its simple, but I'm still a newbie. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Trouble submitting form using database_form
Guys, I am having trouble figuring out why I am getting the wrong number of arguments (1 for 2) when the form is submitted. Here is the form: Name: Email: Favorite Wine: Primary Interest: Any ideas? Thanks, Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Best way to refer to a stylesheet?
Mohit, Thanks, yes: your excellent tutorial was my starting point. But I was having trouble because my Radiant site was in a subdomain. Now I know several ways to handle this. John Mohit Sindhwani wrote: John Allen wrote: This has to be a really basic question, but despite reading the documentation and many mailing list posts, I still don't get it... For stylesheets which are stored in the database 1) In a layout, what is the recommended way to refer to a stylesheet ? 2) In a page, what is the recommended way to refer to a stylesheet ? My stylesheets work fine when I refer to them as files in the filesystem, but not when they are in the database. John Hi John If you have your stylesheet set up as a page in Radiant, you need to know its slug. Once you know the slug, you can render it with something like this in your layout: | This requires you to have a stylesheet under the root of your site in Radiant with a slig of styles.css. | This tutorial of mine very briefly touches on it: http://notepad.onghu.com/2007/5/26/hello-world-using-radiant-cms Cheers, Mohit. 6/9/2008 | 2:35 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant -- John Allen Bofferdange, Luxembourg [EMAIL PROTECTED] http://allenlux.dyndns.org ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] And what happened to the clear page cache button?
Chris and Casper, Yes, indeed. I was away from the computer all day yesterday, but while dozing in the sun I also realised it could be fixed by changing the custom_settings.rb file. However, it only works when I have StylesNScripts::Config[:stylesheet_directory] = '/site3/public/css' In the page source, this gives href="/site3/public/css/styles.css" I should say that - the DocumentRoot is /home/usr/HomePage/Current/ - the Radiant site lives at /home/usr/HomePage/Current/site3/ - and it is accessed through the URL http://allenlux.dyndns.org/radiant3 Something else: testing these changes is quite tedious because each time I have to a) kill the Radiant application with a "killall dispatch.fcgi" at the console b) after Radiant restarts, I have to go into the admin interface and open and save a page to force a flush of the page cache. I wonder - could we have the "flush page cache" button back for situations where no save is involved but we still want to flush everything - and how about a "restart Radiant" button in the admin interface? This is all very educational. I must say that I really do like Radiant! John Chris Parrish wrote: After posting to you on the other thread, I came over here and see that Casper has pointed out: Casper Fabricius wrote: Yes, well that's because you are running radiant in sub-directory; at http://allenlux.dyndns.org/radiant3/ rather than http://allenlux.dyndns.org/. I also see Sean's response and I'll look into incorporating relative_url_for() into the SnS extension. But until then, Styles 'n Scripts is unaware of your subdirectory arrangement and will assume, for instance, that your stylesheets are located in http://allenlux.dyndns.org/css and not http://allenlux.dyndns.org/radiant3/css. I suspect that this won't work since the first url probably wouldn't trigger the TextAssetSiteController -- but I'm not sure either. Can someone test this? In the meantime, you should be able to make this work by changing the default settings via the /styles_n_scripts/custom_settings.rb file. Just uncomment/add the following and restart Radiant: StylesNScripts::Config[:stylesheet_directory] = 'radiant3/css' StylesNScripts::Config[:javascript_directory] = 'radiant3/js' -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant -- John Allen Bofferdange, Luxembourg [EMAIL PROTECTED] http://allenlux.dyndns.org ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] 0.6.7 'edit' not working
10 space characters and it started with v0.6.7? I can almost guarantee it's this: http://dev.radiantcms.org/ticket/642 I'm guessing that you have an extension with it's own Pages edit.html.erb file (or at least contains the textarea element for the page edit form). If so, you can: * Wait for a Radiant fix * Roll back to 0.6.6 * Update your extension to use Haml * Freeze the Radiant Gem and manually edit the offending "=" within Radiant's code On the positive side, your pages have not been changed -- they just look like it. However, if you save them with the spaces there, that's different. -Chris Ben Morrow wrote: I just upgraded 0.6.6 to 0.6.7. I've noticed that " " has been added before each line on my pages. I tried to remove the leading spaces and "Save Changes", but I am redirected to a blank page with the url "../edit/27". There is nothing in page source, and by going back to the admin panel I can see that the updates weren't saved. Any advice? ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
First of all let me say, Jim, that I *really* like your analysis of the "Review Drafts" use case. You are so right that, as a reviewer, I want to focus my attention on the changes not the stuff that's the same. I really hadn't given this issue much thought before you brought it up. That said, I would discourage going down the road of idea #2. Here's why: * To the user, a Page is the atomic unit -- sure, as a developer, I see the Page as a single model/record with mutliple related PagePart models/records but Radiant nicely keeps these implementation details off the UI. It's pages that we create, edit and destroy. This is good because, frankly, it's Pages that are served. * This would make creating a draft different from creating a Page. When we create a Page we don't individually save the Parts -- only pages. But this idea would require the user to work differently with Parts when drafting. * Many users don't get into using page parts. This solution would force Parts into their awareness (sort of a "what? another button? man, what's this one do? Why can't I just save my page?" experience). * Identifying which part has changed doesn't necessarily help me anyway. For example, what if I have a really long Page Part and it's only the bottom paragraph that's been edited? I still end up reviewing all the unchanged content needlessly. Or how do I know that they only changed the Page's slug? Weirder still, what if the writer adds a Part that isn't used in the Page at all? Sure that Part shows that it's been changed but it doesn't alert the reviewer to the fact that they can ignore this Part altogether. Now, back to the bit I *love* from your idea #2... I think we should give the user (writer or reviewer) some sort of analysis of the difference between the currently published version of the page and the current draft. This diff could be as simple as identifying which elements (parts, title, slug, whatever) are different from the currently published version (this is what you suggested) or could even go so far as a source code style diff showing which lines/characters were changed within each element. On a completely different tack, you could also diff the output of both versions to only show relevant edits to the draft. As to how this diff info is presented, you could: * Run the diff when loading the Edit Screen and highlight all the elements in the form that have changed (sort of like highlighting validation errors but with a different look). This lends itself to the basic diff -- just showing which elements have differences within. * Have a button or link for the user to manually run the diff which highlights all the elements that have changed. (Same as above, just manual). * Have a button or link for the user to manually run the diff and pop up a window reporting the findings. This method allows for as basic or complex diff analysis as you like. -Chris Jim Gay wrote: I haven't had time to work on this myself, but I was thinking about the interface and I'm curious to hear how the community expects this to work. Once a site is up and running, I would expect that people would want to use drafts in 2 different ways. 1) each page has a draft. Any and all associated parts would be reviewed prior to publishing. (This is what Jamey described) 2) each page_part has a draft. Users could write drafts for individual parts. I would think that option 2 is what would happen more often. An example I imagine is editing several parts on an "About Us" page. The "introduction" part might rarely change, but the "bios" part may need drafts as staff members come and go. I wouldn't want to be forced to review the "introduction" with each staff change only to find that nothing at all has changed in that part. If we view the entire page as a draft, I would expect that this would be the behavior of the reviewer. On the other side of that coin, I wouldn't want to just assume that the "introduction" part is unchanged when someone actually did change it and made changes that I would not allow if I spent the time to review it. If, however, the reviewer knows that only certain parts have drafts, it makes the reviewing much easier. Whenever I think about drafts, I think of them on a per part basis because users are likely to change content only in important parts, not necessarily all of them. Having a separate "staging" instance increases this problem to need to review the entire site. It's great for a re-launch, but day-to-day changes would be frustrating. There is certainly a lot of interest in "drafts" but aside from Jamey, I haven't heard much about how people expect this to work. I can imagine that, like me, some expectations differ quite a bit from what others expect from "drafts". Does everyone agree with Ja
[Radiant] Re: Re: Re: Admin Tree Extension
Keith Bingman wrote: > This is now on Github at > http://github.com/kbingman/admin_tree_structure/tree/master > It would be great if someone could chekc it out and see if it works > for them. I have it working under the 0.6.6 Gem. If anyone is still using the old drag-and-drop page Reorder extension, be aware that this AdminTreeStructure extension cannot be run alongside of it. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] 0.6.7 'edit' not working
I just upgraded 0.6.6 to 0.6.7. I've noticed that " " has been added before each line on my pages. I tried to remove the leading spaces and "Save Changes", but I am redirected to a blank page with the url "../edit/27". There is nothing in page source, and by going back to the admin panel I can see that the updates weren't saved. Any advice? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
Good question. There are so many ways to skin this cat. I was hoping to hammer out a UI sample at RailsConf, but time just disappeared... Here are my thoughts... - On the page edit screen each page part would have a "create draft" button. That draft would appear above/below the textarea for the selected page part and be clearly marked as the draft for that part. - When saving the page with the created drafts, the drafts are saved and available again when you return to that edit screen. - You could only create 1 draft per page_part. - The tabs for each part with a draft would be styled to mark that it has a draft. - Below the draft textarea would be a button to "use this version" and upon clicking it, the current page_part textarea would disappear and the draft would replace it. - When the page is saved, the selected versions would be copied to the page_parts table. On the page tree, we would need to display how many drafted parts exist for each page, and for its children. This is a little complex since we'd need to display the page's, reviewed parts and drafted parts, and the number of reviewed and drafted parts in the page's children so that a reviewer or admin would know where and when to look for drafts to review or publish. Doing it this way allows us to maintain the idea that an entire page can be draft/reviewed/hidden/published as well as managing a draft of a part within a published page. What this does not allow is the creation of a page_part that is a draft, when a published page_part of the same name for the same page does not yet exist. I think that's an acceptable restriction, but it's only a restriction in my mind because I don't see the need to implement that ability, and I think the concept is more complex than a typical user would need or understand (at this point, at least). It would just muddy the concept. To me, making the page tree appear intuitive is the challenge, but the page editing is simple. On a technical note, I imagine the drafts being stored in a page_parts_drafts table and being copied to the page_parts table, but maintaining the information in page_parts_drafts with a released_at date and version number so that a way could be developed later to view the history or re-release old versions. I think complex versioning is too much to tackle all at once, so we could just leave the data in page_parts_drafts for later. Did I articulate that well enough? I think that users would understand this behavior if presented appropriately. Helpful info like "Once you release this draft, it will replace the current content on your site. There is no undo." But an undo function might come in later, as long as we plan to store all the drafts. -Jim On Jun 9, 2008, at 1:08 PM, Sean Cribbs wrote: Jim, While I agree with your idea in principle, the primary unit of manipulation in the interface is the whole page, including its parts; parts are not edited independently. How do you envision this working? Sean Jim Gay wrote: I haven't had time to work on this myself, but I was thinking about the interface and I'm curious to hear how the community expects this to work. Once a site is up and running, I would expect that people would want to use drafts in 2 different ways. 1) each page has a draft. Any and all associated parts would be reviewed prior to publishing. (This is what Jamey described) 2) each page_part has a draft. Users could write drafts for individual parts. I would think that option 2 is what would happen more often. An example I imagine is editing several parts on an "About Us" page. The "introduction" part might rarely change, but the "bios" part may need drafts as staff members come and go. I wouldn't want to be forced to review the "introduction" with each staff change only to find that nothing at all has changed in that part. If we view the entire page as a draft, I would expect that this would be the behavior of the reviewer. On the other side of that coin, I wouldn't want to just assume that the "introduction" part is unchanged when someone actually did change it and made changes that I would not allow if I spent the time to review it. If, however, the reviewer knows that only certain parts have drafts, it makes the reviewing much easier. Whenever I think about drafts, I think of them on a per part basis because users are likely to change content only in important parts, not necessarily all of them. Having a separate "staging" instance increases this problem to need to review the entire site. It's great for a re-launch, but day-to-day changes would be frustrating. There is certainly a lot of interest in "drafts" but aside from Jamey, I haven't heard much about how people expect this to work. I can imagine that, like me, some expectations differ quite a bit from what others expect from "drafts". Does everyone agree with Jamey, that a
Re: [Radiant] Proposal for a "drafts" or "staging" extension
Jim, While I agree with your idea in principle, the primary unit of manipulation in the interface is the whole page, including its parts; parts are not edited independently. How do you envision this working? Sean Jim Gay wrote: I haven't had time to work on this myself, but I was thinking about the interface and I'm curious to hear how the community expects this to work. Once a site is up and running, I would expect that people would want to use drafts in 2 different ways. 1) each page has a draft. Any and all associated parts would be reviewed prior to publishing. (This is what Jamey described) 2) each page_part has a draft. Users could write drafts for individual parts. I would think that option 2 is what would happen more often. An example I imagine is editing several parts on an "About Us" page. The "introduction" part might rarely change, but the "bios" part may need drafts as staff members come and go. I wouldn't want to be forced to review the "introduction" with each staff change only to find that nothing at all has changed in that part. If we view the entire page as a draft, I would expect that this would be the behavior of the reviewer. On the other side of that coin, I wouldn't want to just assume that the "introduction" part is unchanged when someone actually did change it and made changes that I would not allow if I spent the time to review it. If, however, the reviewer knows that only certain parts have drafts, it makes the reviewing much easier. Whenever I think about drafts, I think of them on a per part basis because users are likely to change content only in important parts, not necessarily all of them. Having a separate "staging" instance increases this problem to need to review the entire site. It's great for a re-launch, but day-to-day changes would be frustrating. There is certainly a lot of interest in "drafts" but aside from Jamey, I haven't heard much about how people expect this to work. I can imagine that, like me, some expectations differ quite a bit from what others expect from "drafts". Does everyone agree with Jamey, that a per page draft is what you'd want? -Jim On Jun 9, 2008, at 12:19 PM, Jamey Cribbs wrote: I agree. I initially wanted to keep everything within one instance of radiant by just modifying the way pages/page_parts were saved and making the additional functionality available through the existing UI. Sean gave me some pointers/lessons learned (including a mention of acts_as_draftable). I still think it is do-able this way, but it would be tricky to incorporate a full-featured draft functionality into the existing architecture and UI without breaking anything in radiant. :) I opted to go the "separate staging instance" route because it appeared more straight forward and it met my clients needs, although the design is not as elegant as being able to do everything in one environment. On Mon, Jun 9, 2008 at 12:01 PM, Chris Parrish < [EMAIL PROTECTED]> wrote: This issue was brought up some time ago so it might be worth checking the maillist history, but I'm not sure anything was ever implemented. One of the interesting things brought up , if I remember correctly, was the mention of Rick Olson's acts_as_draftable plugin. It might be worth looking into (it can be found here: http://svn.techno-weenie.net/projects/plugins/acts_as_draftable/). Drafting functionality is something that Radiant could certainly benefit from. Let us know if you plan to release something. FWIW, I think the biggest challenge would be coming up with a clean, Radiant-worthy UI that lets users perform these functions via an easy-to-understand, concise design. Radiant's UI currently doesn't "think" this way. -Chris Jamey Cribbs wrote: I'm going to ask the client if they would give permission for me to release it. Right now, it only works for mysql, as I'm using mysqldump. Works great for my specific needs, but I might try to genericize it using Sean's export code and fixture loading before I release it. On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: Jamey Cribbs wrote: Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. That's true. I just wanted to point out the obvious
Re: [Radiant] Proposal for a "drafts" or "staging" extension
I haven't had time to work on this myself, but I was thinking about the interface and I'm curious to hear how the community expects this to work. Once a site is up and running, I would expect that people would want to use drafts in 2 different ways. 1) each page has a draft. Any and all associated parts would be reviewed prior to publishing. (This is what Jamey described) 2) each page_part has a draft. Users could write drafts for individual parts. I would think that option 2 is what would happen more often. An example I imagine is editing several parts on an "About Us" page. The "introduction" part might rarely change, but the "bios" part may need drafts as staff members come and go. I wouldn't want to be forced to review the "introduction" with each staff change only to find that nothing at all has changed in that part. If we view the entire page as a draft, I would expect that this would be the behavior of the reviewer. On the other side of that coin, I wouldn't want to just assume that the "introduction" part is unchanged when someone actually did change it and made changes that I would not allow if I spent the time to review it. If, however, the reviewer knows that only certain parts have drafts, it makes the reviewing much easier. Whenever I think about drafts, I think of them on a per part basis because users are likely to change content only in important parts, not necessarily all of them. Having a separate "staging" instance increases this problem to need to review the entire site. It's great for a re-launch, but day-to-day changes would be frustrating. There is certainly a lot of interest in "drafts" but aside from Jamey, I haven't heard much about how people expect this to work. I can imagine that, like me, some expectations differ quite a bit from what others expect from "drafts". Does everyone agree with Jamey, that a per page draft is what you'd want? -Jim On Jun 9, 2008, at 12:19 PM, Jamey Cribbs wrote: I agree. I initially wanted to keep everything within one instance of radiant by just modifying the way pages/page_parts were saved and making the additional functionality available through the existing UI. Sean gave me some pointers/lessons learned (including a mention of acts_as_draftable). I still think it is do-able this way, but it would be tricky to incorporate a full-featured draft functionality into the existing architecture and UI without breaking anything in radiant. :) I opted to go the "separate staging instance" route because it appeared more straight forward and it met my clients needs, although the design is not as elegant as being able to do everything in one environment. On Mon, Jun 9, 2008 at 12:01 PM, Chris Parrish < [EMAIL PROTECTED]> wrote: This issue was brought up some time ago so it might be worth checking the maillist history, but I'm not sure anything was ever implemented. One of the interesting things brought up , if I remember correctly, was the mention of Rick Olson's acts_as_draftable plugin. It might be worth looking into (it can be found here: http://svn.techno-weenie.net/projects/plugins/acts_as_draftable/). Drafting functionality is something that Radiant could certainly benefit from. Let us know if you plan to release something. FWIW, I think the biggest challenge would be coming up with a clean, Radiant-worthy UI that lets users perform these functions via an easy-to-understand, concise design. Radiant's UI currently doesn't "think" this way. -Chris Jamey Cribbs wrote: I'm going to ask the client if they would give permission for me to release it. Right now, it only works for mysql, as I'm using mysqldump. Works great for my specific needs, but I might try to genericize it using Sean's export code and fixture loading before I release it. On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: Jamey Cribbs wrote: Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. That's true. I just wanted to point out the obvious because it is easy to miss it some times (I didn't know about it for quite a while). I remember Sean had a preview extension that would preview the page but again it's not a sta
Re: [Radiant] Proposal for a "drafts" or "staging" extension
A little comment about this, and another "we did that for Redken" story. As Chris said, Radiant's design (visual and workflow) would need to be rethought to accommodate this kind of change. Some kind of versioning (undefined as of yet) is in the roadmap, so we'd appreciate any contributions people can make to the mockups or prototype subprojects to work out the flow. We did this kind of thing for Redken, and I believe DP is still using the extension I wrote. The extension was heavily based on Ticket #503 on Trac. However, as I got it to work, I realized the changes were extremely systemic, similar to what Nick found when trying to scope snippets and layouts in the multi_site extension. There comes a point at which an extension is no longer appropriate. That said, I'd like to see some alternatives to my hackish implementation that we might consider for core down the road. Also, I wrote a quickie extension for a client in December that allowed him to maintain two different Radiant instances, one that's for staging, another for production. We used a sqlite3 database because we could easily copy the file into the production site and it would "just work". Sean Jamey Cribbs wrote: I agree. I initially wanted to keep everything within one instance of radiant by just modifying the way pages/page_parts were saved and making the additional functionality available through the existing UI. Sean gave me some pointers/lessons learned (including a mention of acts_as_draftable). I still think it is do-able this way, but it would be tricky to incorporate a full-featured draft functionality into the existing architecture and UI without breaking anything in radiant. :) I opted to go the "separate staging instance" route because it appeared more straight forward and it met my clients needs, although the design is not as elegant as being able to do everything in one environment. On Mon, Jun 9, 2008 at 12:01 PM, Chris Parrish < [EMAIL PROTECTED]> wrote: This issue was brought up some time ago so it might be worth checking the maillist history, but I'm not sure anything was ever implemented. One of the interesting things brought up , if I remember correctly, was the mention of Rick Olson's acts_as_draftable plugin. It might be worth looking into (it can be found here: http://svn.techno-weenie.net/projects/plugins/acts_as_draftable/). Drafting functionality is something that Radiant could certainly benefit from. Let us know if you plan to release something. FWIW, I think the biggest challenge would be coming up with a clean, Radiant-worthy UI that lets users perform these functions via an easy-to-understand, concise design. Radiant's UI currently doesn't "think" this way. -Chris Jamey Cribbs wrote: I'm going to ask the client if they would give permission for me to release it. Right now, it only works for mysql, as I'm using mysqldump. Works great for my specific needs, but I might try to genericize it using Sean's export code and fixture loading before I release it. On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: Jamey Cribbs wrote: Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. That's true. I just wanted to point out the obvious because it is easy to miss it some times (I didn't know about it for quite a while). I remember Sean had a preview extension that would preview the page but again it's not a staging environment. Your extension does sound interesting. Do you have plans to release it? Cheers, Mohit. 6/9/2008 | 11:15 PM. ___ 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 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant _
Re: [Radiant] Proposal for a "drafts" or "staging" extension
Jamey Cribbs wrote: No, there is a production db and a staging db. The users make all content changes in the staging db. When they are satisfied with changes in staging, they go to the "Staging" admin tab in the staging environment and click on a button, which fires off a mysqldump of selected tables in the staging db and then a mysql -e source on the production db. The production admin radiant environment is disabled, effectively making the production db read-only for users. Ah, I see! Makes sense :) Thanks, Mohit. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: tag documentation feedback
David Piehler wrote: There's been discussion on this mailing list / forum about improving the Radiant documentation and beginner user guides. A few people have stepped-up already and started working on this, and others have it on their to-do list. I personally take meticulous notes during my Radiant installations and upgrades, and plan to turn this into helpful documentation on radiantcms.org this summer. I like your ideas about improving the Admin screen tag documentation, since a lot are missing the list of variables you can pass to the tags. I'm adding this to my summer to-do list as well. OK, I admit it. It's me. I'm the evil one! I really need to find the time to get back to the mini-project for Radiant documentation. I have been completely missing in action, working on an unrelated work project. But, I hope to get back to the Radiant documentation project asap. In fact, I'm checking emails sent to this list 2 months ago! It seems like an age since I have seen/ worked with Radiant! I will send some details in the next couple of weeks. I see good days ahead! Cheers, Mohit. 6/10/2008 | 12:33 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
On Mon, Jun 9, 2008 at 12:22 PM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: > Jamey Cribbs wrote: > >> I agree. I initially wanted to keep everything within one instance of >> radiant by just modifying the way pages/page_parts were saved and making >> the >> additional functionality available through the existing UI. Sean gave me >> some pointers/lessons learned (including a mention of acts_as_draftable). >> I still think it is do-able this way, but it would be tricky to >> incorporate >> a full-featured draft functionality into the existing architecture and UI >> without breaking anything in radiant. :) >> >> I opted to go the "separate staging instance" route because it appeared >> more >> straight forward and it met my clients needs, although the design is not >> as >> elegant as being able to do everything in one environment. >> >> >> > > Does this mean 1 database, 2 Radiants? > > Cheers, > Mohit. > 6/10/2008 | 12:22 AM. > > > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > No, there is a production db and a staging db. The users make all content changes in the staging db. When they are satisfied with changes in staging, they go to the "Staging" admin tab in the staging environment and click on a button, which fires off a mysqldump of selected tables in the staging db and then a mysql -e source on the production db. The production admin radiant environment is disabled, effectively making the production db read-only for users. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
Jamey Cribbs wrote: I agree. I initially wanted to keep everything within one instance of radiant by just modifying the way pages/page_parts were saved and making the additional functionality available through the existing UI. Sean gave me some pointers/lessons learned (including a mention of acts_as_draftable). I still think it is do-able this way, but it would be tricky to incorporate a full-featured draft functionality into the existing architecture and UI without breaking anything in radiant. :) I opted to go the "separate staging instance" route because it appeared more straight forward and it met my clients needs, although the design is not as elegant as being able to do everything in one environment. Does this mean 1 database, 2 Radiants? Cheers, Mohit. 6/10/2008 | 12:22 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
I agree. I initially wanted to keep everything within one instance of radiant by just modifying the way pages/page_parts were saved and making the additional functionality available through the existing UI. Sean gave me some pointers/lessons learned (including a mention of acts_as_draftable). I still think it is do-able this way, but it would be tricky to incorporate a full-featured draft functionality into the existing architecture and UI without breaking anything in radiant. :) I opted to go the "separate staging instance" route because it appeared more straight forward and it met my clients needs, although the design is not as elegant as being able to do everything in one environment. On Mon, Jun 9, 2008 at 12:01 PM, Chris Parrish < [EMAIL PROTECTED]> wrote: > This issue was brought up some time ago so it might be worth checking the > maillist history, but I'm not sure anything was ever implemented. One of > the interesting things brought up , if I remember correctly, was the mention > of Rick Olson's acts_as_draftable plugin. It might be worth looking into > (it can be found here: > http://svn.techno-weenie.net/projects/plugins/acts_as_draftable/). > > Drafting functionality is something that Radiant could certainly benefit > from. Let us know if you plan to release something. > > FWIW, I think the biggest challenge would be coming up with a clean, > Radiant-worthy UI that lets users perform these functions via an > easy-to-understand, concise design. Radiant's UI currently doesn't "think" > this way. > > -Chris > > > Jamey Cribbs wrote: > >> I'm going to ask the client if they would give permission for me to >> release >> it. Right now, it only works for mysql, as I'm using mysqldump. Works >> great for my specific needs, but I might try to genericize it using Sean's >> export code and fixture loading before I release it. >> >> On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: >> >> >> >>> Jamey Cribbs wrote: >>> >>> >>> Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. >>> That's true. I just wanted to point out the obvious because it is easy >>> to >>> miss it some times (I didn't know about it for quite a while). >>> >>> I remember Sean had a preview extension that would preview the page but >>> again it's not a staging environment. Your extension does sound >>> interesting. Do you have plans to release it? >>> >>> Cheers, >>> Mohit. >>> 6/9/2008 | 11:15 PM. >>> >>> >>> ___ >>> 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 >> >> > > ___ > 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] Proposal for a "drafts" or "staging" extension
This issue was brought up some time ago so it might be worth checking the maillist history, but I'm not sure anything was ever implemented. One of the interesting things brought up , if I remember correctly, was the mention of Rick Olson's acts_as_draftable plugin. It might be worth looking into (it can be found here: http://svn.techno-weenie.net/projects/plugins/acts_as_draftable/). Drafting functionality is something that Radiant could certainly benefit from. Let us know if you plan to release something. FWIW, I think the biggest challenge would be coming up with a clean, Radiant-worthy UI that lets users perform these functions via an easy-to-understand, concise design. Radiant's UI currently doesn't "think" this way. -Chris Jamey Cribbs wrote: I'm going to ask the client if they would give permission for me to release it. Right now, it only works for mysql, as I'm using mysqldump. Works great for my specific needs, but I might try to genericize it using Sean's export code and fixture loading before I release it. On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: Jamey Cribbs wrote: Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. That's true. I just wanted to point out the obvious because it is easy to miss it some times (I didn't know about it for quite a while). I remember Sean had a preview extension that would preview the page but again it's not a staging environment. Your extension does sound interesting. Do you have plans to release it? Cheers, Mohit. 6/9/2008 | 11:15 PM. ___ 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 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
I'm going to ask the client if they would give permission for me to release it. Right now, it only works for mysql, as I'm using mysqldump. Works great for my specific needs, but I might try to genericize it using Sean's export code and fixture loading before I release it. On Mon, Jun 9, 2008 at 11:15 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: > Jamey Cribbs wrote: > >> Thanks, but as you said, the "dev" functionality does not do >> everything we need. If you have an existing page that you want to >> change, you have to set the status back to "draft" and then the page >> does not show at all on the production site. >> >> Anyway, after much investigation, I ended up going a totally different >> route. I created a "staging" extension and setup an additional >> radiant environment called "staging". The extension disables all >> admin functions in the production environment and adds an admin tab in >> the staging environment that allows you to click on a link, whereby it >> copies relevant tables from the staging db to the production db. It >> would have been great to not have to run a separate environment, but >> so far it seems to be working well. >> >> > > That's true. I just wanted to point out the obvious because it is easy to > miss it some times (I didn't know about it for quite a while). > > I remember Sean had a preview extension that would preview the page but > again it's not a staging environment. Your extension does sound > interesting. Do you have plans to release it? > > Cheers, > Mohit. > 6/9/2008 | 11:15 PM. > > > ___ > 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] Proposal for a "drafts" or "staging" extension
Jamey Cribbs wrote: Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. That's true. I just wanted to point out the obvious because it is easy to miss it some times (I didn't know about it for quite a while). I remember Sean had a preview extension that would preview the page but again it's not a staging environment. Your extension does sound interesting. Do you have plans to release it? Cheers, Mohit. 6/9/2008 | 11:15 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Re: Radiant 0.6.7 Admin Issue (affecting reorder and copy_mo
Sean Cribbs wrote: > Jon, > > This only occurs in development mode, when extensions are reloaded. The > issue has been resolved in the latest 'edge' version (on GitHub). > > Sean Bingo! Cheers Sean. Jon. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant 0.6.7 Admin Issue (affecting reorder and copy_move)
Jon, This only occurs in development mode, when extensions are reloaded. The issue has been resolved in the latest 'edge' version (on GitHub). Sean Jonathan Mccoy wrote: Hi, I've found a strange cache-like glitch in the admin interface when using a number of "column" plugins (copy_move and reorder), where every time the page is reloaded or an AJAX update is performed (opening children), the columns appear to be cached, and another column re-rendered (see attached screenshot). The development log doesn't show excessive rendering, other than the partial for each row. It resets when the server is restarted (deleting sessions doesn't do anything). Regards, Jon. Attachments: http://www.ruby-forum.com/attachment/2132/Picture_15.png ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Radiant 0.6.7 Admin Issue (affecting reorder and copy_move)
Hi, I've found a strange cache-like glitch in the admin interface when using a number of "column" plugins (copy_move and reorder), where every time the page is reloaded or an AJAX update is performed (opening children), the columns appear to be cached, and another column re-rendered (see attached screenshot). The development log doesn't show excessive rendering, other than the partial for each row. It resets when the server is restarted (deleting sessions doesn't do anything). Regards, Jon. Attachments: http://www.ruby-forum.com/attachment/2132/Picture_15.png -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Proposal for a "drafts" or "staging" extension
Thanks, but as you said, the "dev" functionality does not do everything we need. If you have an existing page that you want to change, you have to set the status back to "draft" and then the page does not show at all on the production site. Anyway, after much investigation, I ended up going a totally different route. I created a "staging" extension and setup an additional radiant environment called "staging". The extension disables all admin functions in the production environment and adds an admin tab in the staging environment that allows you to click on a link, whereby it copies relevant tables from the staging db to the production db. It would have been great to not have to run a separate environment, but so far it seems to be working well. On Sun, Jun 8, 2008 at 2:39 PM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: > Jamey Cribbs wrote: >> >> For our current radiant app, my client is asking for this functionality: >> >> "i'd like to use our current setup of radiant and add a selection >> under "status" called staging. When the staging status is selected, >> we'd have an area we can check the page to make sure it looks and that >> the links work. Then we can change status to published and it would >> be available on the live site. The problem we're going to run into is >> that there are more and more people updating content who have very >> little html knowledge." >> >> >> So, after doing a little investigating, I wrote up this proposal for >> how I would like to solve this problem: >> >> "In the Admin section, under the Pages tab, each page name in the tree >> would have a link next to the name called "draft" if a draft version >> exists. Clicking on the draft version would allow you to edit it and >> also set it's status to "Published". If you did this, it would >> overwrite the "Published" version. You could also delete the draft >> version. You could also click on the page name itself, whereby you >> could edit and delete the published version. If there was only a draft >> version of the page, then only the page name would show up and >> clicking on the page name would take you to the draft version. Here is >> an example of what it would look like: >> >> Products draft >> Resources >> >> In this example, the Products page has both a published version and a >> draft version. The Resources page only has one version. >> >> To preview the draft version of a page, you will be able to go to >> http://dev.location_of_radiant_app which will be a version of the site >> that shows draft pages if they exist, otherwise it shows the published >> page. >> >> Technically, this will be accomplished by creating a new radiant >> extension. The extension will provide for a new table called >> "redrafts" (and a "redrafts_parts" table). The redrafts table will >> mirror the structure of the pages table. When a user creates a new >> page, it will be added to the pages table with a status of draft. This >> will be the page that the user edits when he clicks on the page name >> link on the Pages page. Once the page is ready to publish, the user >> changes it's status to "Published". Now, let's say the user wants to >> edit the page. We need to create a new draft of the page, but we need >> to keep the current published version for production. So, when the >> user goes to the edit screen for the published page, they will be able >> to edit the page and then click a button called "Save as draft". This >> will make a copy of the edited page and save it to the redrafts table. >> Now, the page will have both a drafts link and a link to the published >> page. Once they are ready to publish the new draft, they will be able >> to go to the edit screen of the drafted page, change the status to >> "Published" and save it. This will overwrite the current published >> page in the pages table with the draft page from the redrafts table >> and delete the copy from the redrafts page. >> >> Likewise, if you were to delete the published version of a page that >> also had a draft version. The draft version would automatically be >> moved from the redrafts table to the pages table, but would still have >> a status of "drafted". In other words, whenever only one version of a >> page exists, it must be in the pages table. The redrafts table will >> only hold draft versions of pages that currently have a published >> version. >> >> My plan is to use the Shards extension (which, actually, has been >> incorporated into radiant core in version 0.6.7) to manipulate the >> admin ui to present the "draft" links and the new buttons on the page >> edit screen. To add the back-end model functionality, I will add a >> redrafts migration and also callback methods in the Page model. To add >> the controller functionality, I will need to override some of the >> instance methods of the Pages controller." >> >> >> My thinking for having the extension work this way is that it will be >> as unobtrusive to the current functionality as possible, i.e. if
