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.

Archive

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Silverstripe V Modx and whats "missing"


Reply

7 Posts   10993 Views

Avatar
tazzydemon

6 September 2008 at 6:50pm Community Member, 122 Posts

Sirs

I am an Auckland dev dabbling with SS having built a few sites with Modx. Modx has poor ecommerce support at the moment and frankly drupal and joomla are too article/node oriented and downright perverse fo be of interest.

Things I like about Modx:

1.The ability to splatter snippets of code all over the active pages as I wish, to create truly dynamic pages. This is also a big downside as I then have to go to all sorts of trouble to hide these pages from editors or they can turn them into junk instantly.

2.The ability to select templates on a page by page basis. This is great and I just can't understand why it is hardcoded in the config file in SS

3.Front end editing which is a standard module add-on in Modx.

Questions from this:

Is there a mod for SS to give editor-selectable page-by-page templates or do I have to build one?

Is there the equivalent of the quick edit module for Modx whereby there is a top left floating edit bar (bringing up an edit box) on a page if the user is already logged in to the back end.

Julian

Avatar
olafmol

6 September 2008 at 9:31pm Community Member, 10 Posts

I don't know enough of SS to answer your questions yet, but what i really like about the EZPublish CMS is that their manager-interface is basically just another subsite with a different theme/template-set and functionality. I think this is a very smart, powerfull approach, and hope SS also has an approach that is kind of the same?

To go into your question a littlebit more: this enables you to re-use functionality you used for the admin-site in the public site too, but only for administrator accounts.
A very smart way to enable front-end editting ;)

Olaf

Avatar
Willr

7 September 2008 at 11:53am Forum Moderator, 5511 Posts

1.The ability to splatter snippets of code all over the active pages as I wish, to create truly dynamic pages.

You can do this with silverstripe if you wish you just need to set it up. http://doc.silverstripe.com/doku.php?id=recipes:customising-content-in-your-templates . The thing about silverstripe is the CMS is not there for developers, its designed for people who just want to manage the site and also if you start throwing php code in page contents etc it just gets really messy really quickly. You instead can do like the example - define dynamic things in the code away from the editor and provide them with a varible the editors can call eg $InsertBlah where ever they want to.

2) You could if you wanted make something that set the theme via the backend but again its a design decision of the CMS. Let the people who know what they are doing set the theme, set the styles and just let people use that. This is also why there isnt theme editing panels like wordpress where you can edit styles etc from the backend.

If you were changing the theme all the time then maybe you would want to have a dropdown which selects the theme - it would be simple to create!

3) Front end editing is only done on the blog module as a sort of test of functionality for the concept. If you add a $SilverStripeNavigator to your template file when you are logged into the site you have a bar that has a link to edit this page in the cms.. Or you can do your own homebrew solution in the template

<% if CurrentMember %>
<p><a href="admin/show/$ID">Edit this Page</a></p>
<% end_if %>

Front end editing from my view at least is not as important feature as it just adds another layer of complexity where the CMS is much more suited for editing content and its easy enough to have 2 tabs open. Doesnt mean its not practical for some situations! and you can do it - see the blog. But theres no way you can provide half the features in the CMS in a front end view so you sort of get a hybrid thing that people just use the CMS anyway as it doesnt have XYZ that the CMS does!

Avatar
tazzydemon

7 September 2008 at 12:17pm Community Member, 122 Posts

Install a copy of modx and you will see the quickedit floater on the top left of public pages when logged in bak end as a user with at least module execute rights. Its very handy and I would like to know if it's been done on SS.

Avatar
tazzydemon

7 September 2008 at 12:52pm Community Member, 122 Posts

Dear Willr

Thanks for your reply. Yes indeed the ability to splatter php code all over the page content is not without its drawbacks - as I have discovered and pointed out in my posts. However on my modx site I have several "subsites" so to speak (regional folders with different styles and design) and they have different templates as does the entry page. I might have 4 or 5 different templates going on in the one site so.. quote:

"If you were changing the theme all the time then maybe you would want to have a dropdown which selects the theme - it would be simple to create! "

As I am absolutely new to SS and only really familiar to this extent with modx. Maybe you could point out where to start to add this dropdown template selection functionality, or alternatively how one might divide the site up into different template areas (safer from what you say). This is clearly done already judging by the template folder names.

Julian

Avatar
Willr

7 September 2008 at 1:11pm Forum Moderator, 5511 Posts

In a perfect world our subsites module - which allows you to manage content + templates for different subsites would work perfectly! But currently it isnt ready for general use. As for the code you would need to make a drop down for the theme - as you already know the theme is set via 1 call to SSViewer::set_theme('your theme name') in your _config.php. But it doesn't have to be in the _config at all. Im pretty sure it will work if you defined it on a page type basis.

Depending on how your sites setup or going to be if each section is going to have its own page type then you can define a this in the function init() in the controller of each class

// your custom section page type
<?php
class CustomSectionPage extends Page {}

class CustomSectionPage_Controller extends Page_Controller {

function init() {
SSViewer::set_theme("customsectiontheme");
}

But that would only work if you have a different page type for each different template area. You could go further and make that ''customsectiontheme" dynamic - via a dropdown or a plain text area.. Heres an example of a dropdown

// your custom section page type
<?php
class CustomSectionPage extends Page {

static $db = array("Theme" => "Enum('themea, themeb, themec', 'themea'))");

function getCMSFields() {
$fields = parent::getCMSFields();
$fields->addFieldToTab("Root.Theme", new DropdownField("Theme", "Theme", singleton("CustomSectionPage")->dbObject("Theme")->enumValues());
return $fields;
}

}

class CustomSectionPage_Controller extends Page_Controller {

function init() {
SSViewer::set_theme($this->Theme);
}

So basically that will define a list of themes in the database (you could make it dynamically generated from folder names but thats another thing..) then I am adding a dropdown in the CMS with all the values for the dropdown coming from the database then last setting the theme with the selection in the dropdown.

Avatar
Sam

11 September 2008 at 10:57am Administrator, 685 Posts

1) With regards "splattering snippets of code all over active pages as I wish" - I would probably suggest that you look into the widget system. If you package up your snippets of code as widgets, then you can put together very dynamic sites, and the CMS is still usable by its core audience: content authors working in corporate environments who are familiar with apps like Word and Outlook, but not with web or software development.

2) Changing the *theme* on a page-by-page basis doesn't make a lot of sense to me. A theme is supposed to be a *collection* of templates with a consistent look and feel.

Rather, I think it would be better to have a dropdown that let you select a *template* from within that theme. Right now, the only way to do that is to create another page type, which can get a little heavyweight if you're not adding any extra database fields for that page type.

I've created an enhancement ticket for this: http://open.silverstripe.com/ticket/2791

3) We don't have any in place editing functionality, but if you add $SilverStripeNavigator just before the </body> tag, then logged-in CMS users will get a toolbar down the bottom of the page that lets them open the current page in the CMS.