# Copying a page **URL:** \ **Category:** Radiant CMS\ **Created:** [October 29, 2006, 1:28am UTC](https://www.ruby-forum.com/t/copying-a-page/74004 "2006-10-29T01:28:06Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [October 29, 2006, 1:28am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/1 "2006-10-29T01:28:06Z")
Hi. This may have been discussed before, but I wasn’t able to find a reference to it. I’ve setup a blog (archive) page with several parts: body, extended, comments, sidebar, ecc. and avery time I create a new blog entry I’d have to create a new page with the same structure and the same content for all parts but the body and the extended ones. What is the best/quickest way to copy a page (and its part structure) so that I don’t have to re-enter it by hands? (I recall it may be done via the console but how?) Many thanks in advance. M ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 1, 2006, 1:53pm UTC](https://www.ruby-forum.com/t/copying-a-page/74004/2 "2006-11-01T13:53:34Z")
Hello Maurizio While this is not a perfect solution, you may edit “default.parts” value in table “config” in Radiant’s database. Simply change the list of default page parts. From this moment on every new page will have the set of parts you defined. What I’d like to see in Radiant is parts’ inheritance… – Krzysztof Szafranek > **[szafranek.net](https://szafranek.net/)** > > Krzysztof Szafranek, software engineer ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:44am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/3 "2006-11-07T10:44:41Z")
On Oct 30, 3:33 am, Bodhi [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > then any new page you create will have those parts by default. Thank you Bohdi. A couple of questions: 1. those page parts, which logically could be “inherited” from a sort of “template” page (which has all the parts and their content as required), should be the default, but just for a branch of the site tree, for example for the “/blog” one, and not for the entire site; how can I do this? 2. except for the body and the extended part, also the content of the other parts should be copied (or “inherited”); in other words, how can I copy a page from another (a sister page) including its content? M ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:44am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/4 "2006-11-07T10:44:12Z")
On 29/10/2006, at 8:27 AM, Maurizio B. wrote: > What is the best/quickest way to copy a page (and its part structure) > so that I don’t have to re-enter it by hands? > > (I recall it may be done via the console but how?) > > Many thanks in advance. Maurizio, from the console: ``` g5:/sites/radiant bodhi$ ./script/console >> Radiant::Config['default.parts'] => "body, extended" >> Radiant::Config['default.parts'] = "body, extended, comments, ``` sidebar" =\> “body, extended, comments, sidebar” then any new page you create will have those parts by default. Bodhi ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:45am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/5 "2006-11-07T10:45:05Z")
On 30/10/2006, at 4:00 PM, Maurizio B. wrote: > tree, for example for the “/blog” one, and not for the entire site; > how > can I do this? > > 1. except for the body and the extended part, also the content of the > other parts should be copied (or “inherited”); in other words, how can > I copy a page from another (a sister page) including its content? At the moment, there is no way of copying content from one page to another (apart from copy-and-paste 🙂 ). If you just want to reuse text from another page you could use the ‘inherit=“true”’ attribute, eg: ``` ``` But the part needs to be defined on one of the page’s ancestors, and it’s a reference, not a copy (ie. if you change the part on the ancestor, it will change on ALL the children). Bodhi ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:46am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/6 "2006-11-07T10:46:11Z")
I’m now 3 days into pulling my hair out trying to get a custom calendar/events behavior to do what I need it to. Two questions: 1. I can’t seem to deduce from the code the purpose of page.virtual (or page\_virtual within the behavior context). How is it used? How might the use of it help me in creating a behavior which generates it’s own, well, virtual pages a little like the Archive Behavior. 2. I’m overriding find\_page\_by\_url and taking all the paths above the page with the behavior as parameters to that behavior then outputting the page again… so my find\_page\_by\_url looks simply like this in the behavior: Having went around the routes and everything else in this manner I’m not surprised that my \ **Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:48am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/7 "2006-11-07T10:48:11Z") > 1. those page parts, which logically could be “inherited” from a sort > of “template” page (which has all the parts and their content as > required), should be the default, but just for a branch of the site > tree, for example for the “/blog” one, and not for the entire site; > how > can I do this? This isn’t currently possible, but page templates would be a great feature that I may tackle as corex/APS2 evolves. Either add more info to page\_types or habtm page\_templates, specifying “default” layouts for the page. Plus have a page\_part\_types-esque popup when someone clicks “add child”, default inheriting from the parent? Something like that Would also be great to have Easy Buttons somewhere for “new blog post” or “new clothing item” that post a preprogrammed page\_type/ page\_template & parent\_id. This is adding a lot of tabs to the top though! 🙂 -jamie ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:51am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/8 "2006-11-07T10:51:46Z")
Krzysztof Szafranek wrote: > What I’d like to see in Radiant is parts’ inheritance… Mmm, that’s an interesting thought. So when you create a new page it would have blank parts defined for every one of it’s parent’s parts? You could then delete them or add others, but it would inherit it’s parent’s parts at creation time? – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:51am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/9 "2006-11-07T10:51:54Z")
> Mmm, that’s an interesting thought. So when you create a new page it > would have blank parts defined for every one of it’s parent’s parts? You > could then delete them or add others, but it would inherit it’s parent’s > parts at creation time? I would think a ‘clone’ page would be more useful. It would essentially clone a child page by copying all parts and behavior but no content. the new clone would be a sibling of the page cloned. Cheers, Marty ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:51am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/10 "2006-11-07T10:51:57Z")
Could this be introduced for new pages? For some behaviors you need to create multiple parts. Having these present upfront gives one less thing to explain to the users. The default content could be provided by the behavior. ``` Erik. ``` John W. Long wrote: > Mmm, that’s an interesting thought. So when you create a new page it > would have blank parts defined for every one of it’s parent’s parts? You > could then delete them or add others, but it would inherit it’s parent’s > parts at creation time? – Erik van Oosten > **[Day to day stuff](http://day-to-day-stuff.blogspot.com/)** > > Experiences from a hard core JVM programmer. Likes to keep things simple. ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:49am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/11 "2006-11-07T10:49:11Z")
Loren, It sounds like you’re tackling a hard problem. I also had to tackle some hard conceptual problems when figuring out how to do the Commentable. It will be rewarding, I promise! In doing so, I learned a lot about what makes Radiant tick, even though I already understood Rails. 1. Virtual pages are not directly navigable, but fill some system-specific function for the site. The Archive Month behavior, is a virtual page that generates archive pages on a month basis, but each of those individual pages is not a real page, just generated by the behavior. So for your “events”, you wouldn’t want individual months or days or weeks to be pages, but a virtual page that would show the events for each year/month/day/week dynamically. 2. From the looks of this, yes you want a virtual page. But perhaps you want the technique that the Archive behavior uses, in that it adjusts the children URLs. Or are there no children at all? 3. Every behavior is uncharted behavior until you’ve done it! In retrospect, I would have done a lot of things with Commentable differently, but it works and is quite clever in some respects. It’s commendable that you are taking Radiant with you… it’s the harder path. Sean C. [seancribbs.com](http://seancribbs.com) ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:53am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/12 "2006-11-07T10:53:49Z")
> Could this be introduced for new pages? For some behaviors > you need to > create multiple parts. Having these present upfront gives one > less thing > to explain to the users. The default content could be provided by the > behavior. > > ``` > Erik. > > ``` My preferred way to do that would be to let the parent in on the child creation process - you would create a parent behaviour for, say ‘reviews’, and this parent behaviour would dictate the default parts and behavior of its children. This idea is in part because I would like pages to potentially have their administration page change completely based on their behaviour - I think the best way to do that would be to choose the behavior before being presented with the administration page (so click new -\> choose behavior -\> edit page). To make this less obstrusive, the parent page could dictate what the allowed children were - so you don’t put archive month summarys beneath pages that aren’t archive behaviors, and the ‘reviews’ parent would only allow ‘review’ children (thus skipping the choose behavior page). Or maybe the child pages say what their parents can be… either/or - if your review child page has it’s own behavior, and that behavior is selected before the page object is instantiated, the parts can be selected by the review child behaviour. Simple behaviors that do little more than specify their allowed parents and default parts would be fairly easy to create an admin interface for. Store those in a table and dynamically create their classes on demand. Ruby makes that bit brain-dead easy. But I’ve yet to actually put any of that into an implementation, so I don’t know whether these ideas are actually good or not… ‘when I have time’… dammit… too much thinking not enough doing. Daniel. ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:52am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/13 "2006-11-07T10:52:00Z")
I actually was just in a similar situation, but found that using the sibling’s page parts worked better in my situation as opposed to the parent’s. I wanted to have a “slideshow” section of my site and used the very cool page\_page\_types that Dror created to allow uploading of photos. I however wanted all of the children tabs (page parts) of that section to have the “attachment” attribute, so when I created a new page under that section it automatically would be created with an attachment page part (along with a few other custom page I wanted parts). It was easy to code up something in the page\_controller.rb to just create the @page.parts to use the parent of the new page you were creating. For example: if request.get? @page.parent.parts.each do |part| @page.parts \<\< PagePart.new(:name =\> part.name) end end This might do what some people have asked for. But, I then thought about it more and realized… Ideally, in my situation, I don’t want to have the attachments (or other custom parts) page part types on the slideshow SECTION page. This didn’t make sense to have to put my page parts on the parent. I just needed some way to say only that all of the children of that section should have a predefined set of page parts. The thought then was to make it so when a page is created it would use it’s SIBLING’s page parts. The only way I could think of to do this was to grab the first child of the parent that is being created and use the parts from that. For example, some code like this: if request.get? if @page.parent != nil && @page.parent.children[0] != nil @page.parent.children[0].parts.each do |parts| @page.parts \<\< PagePart.new(:name =\> parts.name, :page\_part\_type\_id=\> parts.page\_part\_type\_id) end else default\_parts.each do |name| @page.parts \<\< PagePart.new(:name =\> name) end end end You have to create one page with the types you want, but then others created in that section will have the same as the first one defined. I appologize for the long post. Just wanted to share my thoughts and see what others thought about this. I think there is some merit to having some sort of “inherit” attributes on creating a page so all the children of that page would have the attributes defined, but just wanted to point out in some cases you might not want to have to set the page part on the parent and instead want to base the new page off it’s siblings. I’m also looking for maybe a good generic way to do this since as of right now I have hacked the core page\_controller.rb to get this to work. Plus, as you can see my code only goes 1 level up, so ideally if we were to have it use the parent’s, it should recurse up to the root page. Keep up the great work on Radiant! Thanks, Justin — “John W. Long” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > parts at creation time? * * * Cheap Talk? Check out Yahoo! Messenger’s low PC-to-Phone call rates ([http://voice.yahoo.com](http://voice.yahoo.com)) ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 11:52pm UTC](https://www.ruby-forum.com/t/copying-a-page/74004/14 "2006-11-07T23:52:45Z")
John W. Long wrote: > Krzysztof Szafranek wrote: > > > What I’d like to see in Radiant is parts’ inheritance… > > Mmm, that’s an interesting thought. So when you create a new page it > would have blank parts defined for every one of it’s parent’s parts? You > could then delete them or add others, but it would inherit it’s parent’s > parts at creation time? Yes, that’s exactly what I meant. Inheritance doesn’t clutter current interface, while simplify the mundane task of setting up each new page. For me it would also eliminate the need for “cloning” functionality, but maybe this one could also be useful. BTW John: thanks for the work you’ve done on Radiant. I really love its philosophy and elegant design. ---
**Author:** ![Maurizio\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b3f665/32.png) [@Maurizio\_B](https://www.ruby-forum.com/u/Maurizio_B)\ **Post date:** [November 7, 2006, 10:59am UTC](https://www.ruby-forum.com/t/copying-a-page/74004/15 "2006-11-07T10:59:07Z")
> I would think a ‘clone’ page would be more useful. It would > essentially clone a child page by copying all parts and behavior but > no content. the new clone would be a sibling of the page cloned. I like the “clone” command approach. It is a pragmatic one, probably relatively easy to implement (but maybe I’m wrong), and easy to understand for end users. In the case you need a clone of a sibling page, you just clone the page, and a new sibling is created with a new title/slug which you could change later (or contextually within the cloning page–an input box pops up and request you the new title otherwise a default is used); in the case of children, you create the first child by hands (or by inheritance when and if available), and then clone it to create a new page. I’d like to stress it would be very useful to also have the part content pre-filled by the cloning process (eventually this could be optional), because in many cases some page parts could contain a snippet which is in common among all cloned pages (think of config part in commentable, by way of example). I’d think providing a clone button shouldn’t be hard.