Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Customising the CMS /

Remove page type from Create dropdown in CMS


Reply


8 Posts   1527 Views

Avatar
omarkohl

Community Member, 30 Posts

19 February 2011 at 2:32am

Basically what I wanted to do is enable only 1 instance of a certain page type (BannerPage) in the site tree.

Overloading the canCreate() function in the BannerPage class works fine but not if you don't reload the backend after creating or deleting a BannerPage. Apparently canCreate() is only checked once when the backend is loaded and without reloading it allows you to create several instances of the page or (after deleting) doesn't re-enable the creation (only after reloading).

To overcome this problem I overrode the onBeforeWrite() function to exit() if an instance of BannerPage exists.

This solves my problem because it is not possible to create more than one instance of BannerPage but has 2 disadvantages:

1. After deleting the only instance of BannerPage no new instance can be created except after reloading the backend
2. No error message is shown to the user when trying to create more BannerPages (it simply doesn't work no matter how often you click) and this might be a little confusing (for him/her)

Anyone has a better solution for this?

Avatar
swaiba

Forum Moderator, 1799 Posts

19 February 2011 at 3:06am

I would control it by having any required data for the page stored else where and then creating it as a hidden page... that is loaded based on a director rule.

_config.php

Director::addRules(100,array(
'myonetimepage' => 'MyOneTimePage_Controller',
));

class MyOneTimePage extends Page implements HiddenClass {}
class MyOneTimePage_Controller extends Page_Controller {
   //stuff
}

Avatar
omarkohl

Community Member, 30 Posts

19 February 2011 at 5:02am

Edited: 19/02/2011 5:02am

I'm asuming that HiddenClass hides the Page in the Site tree right? This is not what I need because the user has to be able to edit the content of this BannerPage.

Avatar
swaiba

Forum Moderator, 1799 Posts

19 February 2011 at 5:08am

Fine with me, just prompting a very clean option for hiding a page from the site tree.

And please note I did say "any required data for the page stored else where" the site tree is very slow and not the right place for a lot of the information people store there. For my "system pages" as I call them I have one data object with the options in it editable via ModelAdmin or it can be linked to another page.

Avatar
omarkohl

Community Member, 30 Posts

19 February 2011 at 6:50am

Edited: 19/02/2011 6:52am

Actually BannerPage is never displayed in the frontend. It is just a "Data-Store" for Banners which are then displayed on several pages according to different rules.

Maybe it would make more sense to convert the whole thing to a DataObject instead (because it has nothing to do with a page after all). The reason I did it this way is to have somewhere to edit those Banners. I thought about making it a Tab on some other page but somehow it seemed not right and the separation was clearer when creating a single separate Page just for this.

So reformulating the whole question: How would you do this? Have a "Data-Store" to save all banners and information such as click-rate, etc. and a place to edit those banners. The main point is to make it for the whole site, not just for a single page, because Banners can be displayed anywhere and the data gathered is displayed in a backend report.

Avatar
swaiba

Forum Moderator, 1799 Posts

19 February 2011 at 8:48am

Try ModelAdmin...

http://doc.silverstripe.org/sapphire/en/reference/modeladmin
http://www.silverstripe.org/making-a-crm-with-modeladmin-in-silverstripe-230/

Avatar
omarkohl

Community Member, 30 Posts

19 February 2011 at 10:15am

Edited: 19/02/2011 10:26am

Great! :-D That looks pretty much like what I'm looking for.

Thanks!

Avatar
swaiba

Forum Moderator, 1799 Posts

20 February 2011 at 9:06pm

You are very welcome - to me ModelAdmin is an amazing feature of ss. However I am very curious about ss v3 UI updates as when Ingo says "people know their datamodel and are willing to compromise on UI" in that presentation - I wish the folks I dealt with would...