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
>> 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
>> 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
>> 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 a
>> user never needs to create a new draft of an existing page, then the
>> extension won't come into play and things will function as if this
>> extension does not exist.
>> My question for this mailing list is, does my proposed extension sound
>> do-able? Is there an easier/better way for me to accomplish this?
>> Anything I missed?
>> Any advice or suggestions would be greatly appreciated.
>> Jamey Cribbs
> If your site is installed to http://www.example.com/ Radiant serves up a
> 'draft' version at http://dev.example.com/ if I remember correctly. You can
> change the subdomain by setting it in the Radiant config under
> environment.rb as mentioned here:
> Not sure if it does *all* of what you want, though...
> 6/9/2008 | 2:38 AM.
> 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