Single page and themes
Permalink
Hi,
So I added a new single page (outside of the dashboard). How do I make it so it uses the default left side bar layout?
So I added a new single page (outside of the dashboard). How do I make it so it uses the default left side bar layout?
bump
In fact, what I would like to do is when I browse my single page in edit mode, when I click on "design" the usual left/right side bars options are there.
Instead of saying "This page is a single page, which means it doesn't have a page type associated with it.
I would need an answer quickly if possible.
Instead of saying "This page is a single page, which means it doesn't have a page type associated with it.
I would need an answer quickly if possible.
> So I added a new single page (outside of the dashboard).
> How do I make it so it uses the default left side bar layout?
You can't that I know of. A single page has its own unique layout. What are you using the single page for? Perhaps a single page is not necessary in your situation?
-Steve
> How do I make it so it uses the default left side bar layout?
You can't that I know of. A single page has its own unique layout. What are you using the single page for? Perhaps a single page is not necessary in your situation?
-Steve
For single pages that live outside the dashboard, you must modify your theme's view.php file and put whatever kind of layout in there with html and css (the contents of the single_page get outputted to the $innerContent variable that you place in your view.php file).
If you need to have different layouts for different single pages, you'll need to make a different theme for each one and set the theme that goes with each single_page in your config/site_theme_paths.php file.
If you wanted to bring in the dashboard theme to a page that doesn't live under the dashboard, perhaps you can set that in config/site_theme_paths.php as well (to 'dashboard')?
If you need to have different layouts for different single pages, you'll need to make a different theme for each one and set the theme that goes with each single_page in your config/site_theme_paths.php file.
If you wanted to bring in the dashboard theme to a page that doesn't live under the dashboard, perhaps you can set that in config/site_theme_paths.php as well (to 'dashboard')?
FWIW, I still have a hard time understanding the need for single pages. It seems to me to be a layer of complexity that just isn't needed.
It leaves me wondering if there's just not a lot of history to the way C5 has evolved that makes eliminating the notion of single pages difficult.
And yes, I've read the docs and I understand how and when they are used. I just don't understand WHY they are needed.
What exactly can a single page do that a "regular" page cannot?
-Steve
It leaves me wondering if there's just not a lot of history to the way C5 has evolved that makes eliminating the notion of single pages difficult.
And yes, I've read the docs and I understand how and when they are used. I just don't understand WHY they are needed.
What exactly can a single page do that a "regular" page cannot?
-Steve
Single Pages are *very* useful when you have very customized functionality that doesn't need to be in the form of a block (or would be too much effort to contort into block form). They aren't of any use to designers or end-users -- only developers.
I think the prime example is if you have a complicated form that is only on one page (so you don't need to re-use it and be able to place it on other pages) -- like if there were a ton of fields, or it spanned multiple pages, or needed to pull in data from an external web service, or had fields and validation that's more complicated than the built-in form block gives you.
A "real-world" example that I ran across once was I had to build a site that had a "quiz" on it. There were 5 different pages of quiz questions, and users were only allowed to proceed to the next page if they got the current page's questions correct. If they got some incorrect, it would show them which were right and which were wrong, and show some clues for the wrong ones. We also had to track how far everyone got in the quiz, and if they completed it their user profile got flagged so they had access to other protected areas of the site. Unfortunately for me at the time (this was a few years ago), we built the site in Drupal, which made it immensely difficult because it doesn't have the single_page functionality that concrete5 does (or if it did, I wasn't aware of it). Building this as a block didn't make sense because the site editors were never editing the quiz -- once we had it worked out it was set on those pages.
The aspect of single_pages that makes this great, by the way, is that they stay out of your way -- you just put any kind of php code in the controller that you want, and you don't have to bend in contortions to work around the system.
So in most straightforward sites, like brochureware or artist portfolio or small business ecommerce, you never need to use them. But if you ever need to build a complex site for a demanding client, it is really nice to have.
Hope that explains it!
-Jordan
I think the prime example is if you have a complicated form that is only on one page (so you don't need to re-use it and be able to place it on other pages) -- like if there were a ton of fields, or it spanned multiple pages, or needed to pull in data from an external web service, or had fields and validation that's more complicated than the built-in form block gives you.
A "real-world" example that I ran across once was I had to build a site that had a "quiz" on it. There were 5 different pages of quiz questions, and users were only allowed to proceed to the next page if they got the current page's questions correct. If they got some incorrect, it would show them which were right and which were wrong, and show some clues for the wrong ones. We also had to track how far everyone got in the quiz, and if they completed it their user profile got flagged so they had access to other protected areas of the site. Unfortunately for me at the time (this was a few years ago), we built the site in Drupal, which made it immensely difficult because it doesn't have the single_page functionality that concrete5 does (or if it did, I wasn't aware of it). Building this as a block didn't make sense because the site editors were never editing the quiz -- once we had it worked out it was set on those pages.
The aspect of single_pages that makes this great, by the way, is that they stay out of your way -- you just put any kind of php code in the controller that you want, and you don't have to bend in contortions to work around the system.
So in most straightforward sites, like brochureware or artist portfolio or small business ecommerce, you never need to use them. But if you ever need to build a complex site for a demanding client, it is really nice to have.
Hope that explains it!
-Jordan
Yeah, they were kind of born out of the practice of seeing one-off templates appear forever in systems like Wordpress: I don't need to see my dashboard pages or my login page appear as a template that I can re-use; I know I only need to use it once. But I still like the fact that it creates a concrete5 page, and I like the fact that it uses the same model-view-controller architecture as reusable page types.
> You wouldn't want to see "Dashboard > Sitewide Settings" as a page type when adding a new page type,
> whether it was when adding new pages or even when browsing your page type list.
Whether, where, and how various page types appear in the administrative UI is a separate issue. I can imagine something like page TYPE attributes that could control how they're handled behind the scenes. Page TYPE attributes would be different from page INSTANCE attributes (which already exist in C5).
Besides that, doesn't the current advanced permissions scheme allow you to specifiy which users can add which page types? So specially designated page types wouldn't have to clutter the administrative UI for users who shouldn't see them.
> Single pages only get used once,
Or so you might think initially. The docs cite a log-in page as the "perfect" example of a single page, yet I can imagine scenarios where one might have a need for 2 (or more) completely different log-in pages for the same site.
Don't get me wrong. I'm not averse to the notion of what a single page allows you to do. I totally understand and appreciate that. I'm simply saying that I'm not able to think of anything they allow you to do that couldn't be accomplished just as easily (and as well) using other C5 features which don't require learning new concepts, procedures, and behaviors that are specific to single pages.
In other words, the following considerations are specific to single pages...
* the $innerContent variable
* having to edit a special config file to change the theme
* the fact that a single page will be wrapped by the current theme ONLY IF the system theme is
overridden in site_theme_paths.php and ONLY IF there's not a like-named file in the current theme.
* You can't edit them in the "usual" manner - i.e. can't add blocks via the UI (at least as far as I can tell)
It just seems to be a lot of unnecessary detail and special behavior to remember for what amounts to a regular old C5 page in all ways but its intended use.
Anyway, I've yet to use a single page for anything on a site aside from the log-in page (which was already implemented as a single page, so I just customized it as described in the docs, but in retrospect I could just as well have done it with a custom form).
When I've needed to implement custom one-off page functionality, I either:
* Use an external form block if there's significant server-side logic required - i.e. something that warrants a custom controller.
OR
* Use an HTML (or other) block with a custom view template if there's only special client-side logic to implement. I just code the custom JS directly into the custom block's view template.
I can even EASILY apply a special theme to any such custom page if necessary via the standard theme selection mechanism (Design button) when editing a page - i.e. no monkeying with config files. In fact, I created a special theme called "Blank Slate" which, as the name implies, gives me completely bare bones pages to work with (easiest theme I ever created!)
Anyway, some day I might encounter a need for a single page (outside having to do so for a dashboard package or something), and I might then appreciate its unique advantages. As of yet, though, I haven't had the need, and I see no advantage.
-Steve
> whether it was when adding new pages or even when browsing your page type list.
Whether, where, and how various page types appear in the administrative UI is a separate issue. I can imagine something like page TYPE attributes that could control how they're handled behind the scenes. Page TYPE attributes would be different from page INSTANCE attributes (which already exist in C5).
Besides that, doesn't the current advanced permissions scheme allow you to specifiy which users can add which page types? So specially designated page types wouldn't have to clutter the administrative UI for users who shouldn't see them.
> Single pages only get used once,
Or so you might think initially. The docs cite a log-in page as the "perfect" example of a single page, yet I can imagine scenarios where one might have a need for 2 (or more) completely different log-in pages for the same site.
Don't get me wrong. I'm not averse to the notion of what a single page allows you to do. I totally understand and appreciate that. I'm simply saying that I'm not able to think of anything they allow you to do that couldn't be accomplished just as easily (and as well) using other C5 features which don't require learning new concepts, procedures, and behaviors that are specific to single pages.
In other words, the following considerations are specific to single pages...
* the $innerContent variable
* having to edit a special config file to change the theme
* the fact that a single page will be wrapped by the current theme ONLY IF the system theme is
overridden in site_theme_paths.php and ONLY IF there's not a like-named file in the current theme.
* You can't edit them in the "usual" manner - i.e. can't add blocks via the UI (at least as far as I can tell)
It just seems to be a lot of unnecessary detail and special behavior to remember for what amounts to a regular old C5 page in all ways but its intended use.
Anyway, I've yet to use a single page for anything on a site aside from the log-in page (which was already implemented as a single page, so I just customized it as described in the docs, but in retrospect I could just as well have done it with a custom form).
When I've needed to implement custom one-off page functionality, I either:
* Use an external form block if there's significant server-side logic required - i.e. something that warrants a custom controller.
OR
* Use an HTML (or other) block with a custom view template if there's only special client-side logic to implement. I just code the custom JS directly into the custom block's view template.
I can even EASILY apply a special theme to any such custom page if necessary via the standard theme selection mechanism (Design button) when editing a page - i.e. no monkeying with config files. In fact, I created a special theme called "Blank Slate" which, as the name implies, gives me completely bare bones pages to work with (easiest theme I ever created!)
Anyway, some day I might encounter a need for a single page (outside having to do so for a dashboard package or something), and I might then appreciate its unique advantages. As of yet, though, I haven't had the need, and I see no advantage.
-Steve
Hey Steve,
I really appreciate your thoughtful questioning on this -- I'm definitely reconsidering some of my previous assumptions about this stuff.
About your "specific to single pages" list:
* I think that $innerContent is kind of random -- might be easier for people to understand if it looked more like the code for outputting areas (not sure what that would be exactly, though)
* Having to edit a special config file doesn't make sense to me either -- seems like it's probably leftover from an old architecture that never got updated (??)
* Note that you *can* add blocks to single_pages -- but only if there's some code in your theme's view.php file that outputs an editable area (so if you put <?php $a = new Area('Main'); $a->display($c); ?> in your view.php file, you will then be able to add blocks) -- but these blocks will be in addition to the content that's outputted by the single_page view file (because that's the whole point of having single_pages).
-Jordan
I really appreciate your thoughtful questioning on this -- I'm definitely reconsidering some of my previous assumptions about this stuff.
About your "specific to single pages" list:
* I think that $innerContent is kind of random -- might be easier for people to understand if it looked more like the code for outputting areas (not sure what that would be exactly, though)
* Having to edit a special config file doesn't make sense to me either -- seems like it's probably leftover from an old architecture that never got updated (??)
* Note that you *can* add blocks to single_pages -- but only if there's some code in your theme's view.php file that outputs an editable area (so if you put <?php $a = new Area('Main'); $a->display($c); ?> in your view.php file, you will then be able to add blocks) -- but these blocks will be in addition to the content that's outputted by the single_page view file (because that's the whole point of having single_pages).
-Jordan
> Note that you *can* add blocks to single_pages -- but
> only if there's some code in your theme's view.php file
> that outputs an editable area
Aha, got it! Still not something that would cause me to opt for a single page, though, since the same thing can be done with a regular page, and a regular page offers more flexibility.
-Steve
> only if there's some code in your theme's view.php file
> that outputs an editable area
Aha, got it! Still not something that would cause me to opt for a single page, though, since the same thing can be done with a regular page, and a regular page offers more flexibility.
-Steve
> The aspect of single_pages that makes this great, by the
> way, is that they stay out of your way -- you just put any
> kind of php code in the controller that you want, and you
> don't have to bend in contortions to work around the
> system.
So why wouldn't an external form block have worked for your quiz? It seems ideally suited to the task. External forms can have their own controllers as well.
The documentation for single pages states the following...
> The keyword here is "form." Single Pages are made for
> solving complex, interactive problems on your site.
> Once we have a single page in place, we'll inevitably
> need to process some form that's contained on it.
So again, why not an external form block?
And BTW, I think that block has a very misleading/confusing name. "Custom Form Block" would be more appropriate. I have no idea what it's "external" to. It really just allows for much more flexibility in the layout and behavior of your form - i.e. allows for "custom" appearance and functionality.
-Steve
> way, is that they stay out of your way -- you just put any
> kind of php code in the controller that you want, and you
> don't have to bend in contortions to work around the
> system.
So why wouldn't an external form block have worked for your quiz? It seems ideally suited to the task. External forms can have their own controllers as well.
The documentation for single pages states the following...
> The keyword here is "form." Single Pages are made for
> solving complex, interactive problems on your site.
> Once we have a single page in place, we'll inevitably
> need to process some form that's contained on it.
So again, why not an external form block?
And BTW, I think that block has a very misleading/confusing name. "Custom Form Block" would be more appropriate. I have no idea what it's "external" to. It really just allows for much more flexibility in the layout and behavior of your form - i.e. allows for "custom" appearance and functionality.
-Steve
Buhh.... whoah -- I never noticed what the external form block actually does before (I always assumed it was for pasting in JS snippets you get from other services like MailChimp or Constant Contact).
Misleading name indeed.
So yeah I can't really say off the top of my head why you wouldn't use that, other than perhaps there's a bunch of legacy code you have and you don't want to rewrite it in c5 controller/view format??
Misleading name indeed.
So yeah I can't really say off the top of my head why you wouldn't use that, other than perhaps there's a bunch of legacy code you have and you don't want to rewrite it in c5 controller/view format??
> I never noticed what the external form block actually does before
For the sake of anyone who stumbles upon this thread and wants a quick start overview of how to create one of those mysteriously named "External Forms" [Twilight Zone music here], see the first reply by "da man" himself (Andrew) in this thread...
http://www.concrete5.org/community/forums/chat/external_forms_file_...
-Steve
For the sake of anyone who stumbles upon this thread and wants a quick start overview of how to create one of those mysteriously named "External Forms" [Twilight Zone music here], see the first reply by "da man" himself (Andrew) in this thread...
http://www.concrete5.org/community/forums/chat/external_forms_file_...
-Steve
The dashboard is completely created out of single pages. You wouldn't want to see "Dashboard > Sitewide Settings" as a page type when adding a new page type, whether it was when adding new pages or even when browsing your page type list. Single pages only get used once, and live at the location that the filesystem dictates (in your concrete5 site) but they are pages: they can have blocks added to them, and they can have permissions attached to them, which is important in a number of situations.
I think what shotster is asking is more about single_page vs. building a block (as opposed to single_page vs. page type). In theory, you could have made one page type for all of the dashboard pages (because they all have the same layout with the sidebar on the left, etc.), and each page had custom block in it (so a "Sitewide Settings" block). And if someone wanted to add a custom dashboard page for their package, they'd have to create a block to add to the dashboard. That would be *really* horrible (much more so than having a bunch of one-off page types), and hence I think is a more convincing argument for single_pages -- which we can all agree at this point are awesome.
:)
-Jordan
:)
-Jordan
> And if someone wanted to add a custom dashboard page
> for their package, they'd have to create a block to add to
> the dashboard. That would be *really* horrible
I've not yet created a dashboard page, but what could be so horrible about supplying a controller file and a custom view file? That seems pretty much like what I understand is currently required for a dashboard page.
-Steve
> for their package, they'd have to create a block to add to
> the dashboard. That would be *really* horrible
I've not yet created a dashboard page, but what could be so horrible about supplying a controller file and a custom view file? That seems pretty much like what I understand is currently required for a dashboard page.
-Steve
I meant having to create all of the infrastructure for a block -- db.xml, add.php and view.php (which wouldn't really do anything because a dashboard page is always for editing it seems), etc. Also the confusion of having them be blocks so they might disappear from pages if users started experimenting.
> I meant having to create all of the infrastructure for a block
But IF dashboard pages were implemented as a type of custom form block, I don't think you'd have to supply that information, as the underlying block structure would likely be predefined by "the system." You would in effect be providing a custom implementation of an instance of that block, which basically means a controller and custom view template - much like a single page now.
Anyway, the implementation of dashboard pages is not likely to change any time soon, so we have no choice there; but at least there are other options for one's own "single page" implementations.
-Steve
But IF dashboard pages were implemented as a type of custom form block, I don't think you'd have to supply that information, as the underlying block structure would likely be predefined by "the system." You would in effect be providing a custom implementation of an instance of that block, which basically means a controller and custom view template - much like a single page now.
Anyway, the implementation of dashboard pages is not likely to change any time soon, so we have no choice there; but at least there are other options for one's own "single page" implementations.
-Steve
Hi peeps, forgive the ignorance of a newbie.
Can anyone help with the following?
I need to copy the left side page template from my existing theme and then reduce the left menu width (and increase main body). I have the following challenges:
- Theme has been customised by an ex-designer, he left several customised themes in there so I dont know where to look to see which theme I am actually using (I even ran previews but they dont look anything like my pages).
- I need to know exact CSS/HTML code I need to edit once I get past the later stage.
Please any help would be great.
Lucas
Can anyone help with the following?
I need to copy the left side page template from my existing theme and then reduce the left menu width (and increase main body). I have the following challenges:
- Theme has been customised by an ex-designer, he left several customised themes in there so I dont know where to look to see which theme I am actually using (I even ran previews but they dont look anything like my pages).
- I need to know exact CSS/HTML code I need to edit once I get past the later stage.
Please any help would be great.
Lucas
I can help you out. Whats the url of the page you want modified?
Hi, thanks a lot for quick response.
This page (http://liquid-nexxus.com/index.php/trainings/) is using standard left side page from the famous page type I cant find.
As you can see the page looks weird so I am playing with the CSS of the add-on and I think I may need to play with the page and widen it slightly, so I can fit 3 thumbnails
This page (http://liquid-nexxus.com/index.php/trainings/) is using standard left side page from the famous page type I cant find.
As you can see the page looks weird so I am playing with the CSS of the add-on and I think I may need to play with the page and widen it slightly, so I can fit 3 thumbnails
Lucas, I've sent you a PM.
