1 theme, multiple sub-sites, and global areas
Permalink
Hey all,
I've got an issue I'm trying to tackle as elegantly as possible in c5, and wanted to see what the community's thoughts were.
Basically, I've got a very large (5k pages+) website. We have alot of departments that I'm treating as "sub-sites" and have started allowing their editors to use different themes from the marketplace outside our own theme, as long as I can brand it properly and it's responsive. Up until now, this has worked great for building.
But now I've reached a point where a few departments have chosen, and I've customized, some pretty solid themes. There are other departments that could now benefit greatly from being able to use these themes at this point as they build out their own. This is in situations where the departments fit into a similar category, like Art and Music.
The issue I'm having is how to best plug in global areas in the theme for each department to be able to use their own logo, navigation, and footer areas as a global stack.
At first, I thought "Page Attribute" with a dropdown list of departments. Then I check for that attribute in the theme, and create a global area based on the text there, effectively creating me a "Art-Nav" and "Music-Nav" global stack to tap into.
The problem I see already is this page attribute has to be set every time a page is created.
While not difficult, I could see it easily being overlooked, esp. in instances where we use a blog of event calendar to publish. The publisher will have to visit each post and set this attribute.
Just seems like there's a better method out there, I'm just not thinking of it.
So who's got the brightest idea on how to solve this tricky issue?
I've got an issue I'm trying to tackle as elegantly as possible in c5, and wanted to see what the community's thoughts were.
Basically, I've got a very large (5k pages+) website. We have alot of departments that I'm treating as "sub-sites" and have started allowing their editors to use different themes from the marketplace outside our own theme, as long as I can brand it properly and it's responsive. Up until now, this has worked great for building.
But now I've reached a point where a few departments have chosen, and I've customized, some pretty solid themes. There are other departments that could now benefit greatly from being able to use these themes at this point as they build out their own. This is in situations where the departments fit into a similar category, like Art and Music.
The issue I'm having is how to best plug in global areas in the theme for each department to be able to use their own logo, navigation, and footer areas as a global stack.
At first, I thought "Page Attribute" with a dropdown list of departments. Then I check for that attribute in the theme, and create a global area based on the text there, effectively creating me a "Art-Nav" and "Music-Nav" global stack to tap into.
The problem I see already is this page attribute has to be set every time a page is created.
While not difficult, I could see it easily being overlooked, esp. in instances where we use a blog of event calendar to publish. The publisher will have to visit each post and set this attribute.
Just seems like there's a better method out there, I'm just not thinking of it.
So who's got the brightest idea on how to solve this tricky issue?
Well, one way to do it would be by searching the URL path.
This works, but seems really flimsy.
Alternatively, I thought $nh->getTrailToCollection($c); would be of use. Something like this:
With "4227" being the specific "Art" page's cID. However, this didn't work.
But seems much more robust.
Anyone out there that can point me in the right direction / strengthen what I've got / Got New Approach?
Thanks in advance!
$nh = Loader::helper('navigation'); $pagePath = $nh->getLinkToCollection($c); $pagePath_Pieces = explode('/',$pagePath); print_r(array_change_key_case ( $pagePath_Pieces , CASE_LOWER )); if(in_array('art',$pagePath_Pieces)) { $a = new GlobalArea('Art Logo'); $a->display(); }
This works, but seems really flimsy.
Alternatively, I thought $nh->getTrailToCollection($c); would be of use. Something like this:
$pagesArray = $nh->getTrailToCollection($c); if(in_array('4227', $pagesArray)) { $a = new GlobalArea('Art Logo'); $a->display(); }
With "4227" being the specific "Art" page's cID. However, this didn't work.
But seems much more robust.
Anyone out there that can point me in the right direction / strengthen what I've got / Got New Approach?
Thanks in advance!
Okay, got something that works pretty good.
Now I'm hoping the community can help me refine it or point out issues that may arise.
Here's how I did it:
So far, so good.
I did run into the issue of the theme that's being used has 2 header files, one for homepage, one for all other pages. So in this case I had to target the homepage's parent ID instead of the page itself.
Would love some feedback on this, and hope it helps someone else!
Now I'm hoping the community can help me refine it or point out issues that may arise.
Here's how I did it:
global $c; $nh = Loader::helper('navigation'); $cobj = $nh->getTrailToCollection($c); $rcobj = array_reverse($cobj); /** * List of sub-site by cID that we need to check for. Add more as needed */ $SubSite1 = '3980';//Page's cID $SubSite2 = '4227'; $SubSite3 = '378'; if(is_object($rcobj[1])) { //Home Page loaded as an object //Loop thru the array foreach ($rcobj as $pageLevel) { $pID = $pageLevel->getCollectionID(); $v = View::getInstance(); $theme = $v->getThemeHandle(); //Get the theme, useful to have for customization
Viewing 15 lines of 27 lines. View entire code block.
So far, so good.
I did run into the issue of the theme that's being used has 2 header files, one for homepage, one for all other pages. So in this case I had to target the homepage's parent ID instead of the page itself.
Would love some feedback on this, and hope it helps someone else!
Hi PatrickHenry,
I've been following this thread and it sounds like an interesting, yet challenging, problem.
For context, are you able to provide links to the site and the subsections that are using custom themes?
A few semi-related questions.
How is performance on a site this large?
Have you come up with any tricks for managing users and permissions (I am assume there are probably quite a few users)?
Any other thoughts on dealing with a site this large?
I've been following this thread and it sounds like an interesting, yet challenging, problem.
For context, are you able to provide links to the site and the subsections that are using custom themes?
A few semi-related questions.
How is performance on a site this large?
Have you come up with any tricks for managing users and permissions (I am assume there are probably quite a few users)?
Any other thoughts on dealing with a site this large?
Yeah, it was a real stumper to me at first. But I think I've really ended up with something solid.
By education I come from a design background and have learned PHP somewhat along the way. I'm no noob to PHP, but earlier felt as if I was missing some key aspect of c5 that could be leveraged here to do the job easily.
I'm happy to say:
1) I've become a better programmer than I thought
2) c5 has everything I need to keep the job simple
3) I've gotten even deeper into c5 than ever before, and still find it a delight :)
Ultimately what I've ended up doing was:
A) Already was using config/site_theme_paths.php file for various custom c5 single_pages like login, 404, etc. Using that file that's already being loaded by the dispatcher, I've setup some theme detection that should be really extendable in the future:
This allows me to extend any theme the way I need via c5 dispatcher by adding theme detection and including my detection tool, department_theme_check.php:
This gives me a variable for each theme to detect by.
Then, in my theme file, I can call the site_theme_paths.php, which calls the theme detection tool above and gives me theme variables to work with in the theme itself. Effectively allowing me to setup custom global stacks for thinks like logo, nav, footer using 1 theme, with easy variety.
Is this the right way to do this? No idea. Probably not. I'm hoping the community can help refine it. But as it, it works for my purposes very elegantly (I think).
In response to your other questions:
• Site size, going by cID number only is approaching 5,000. I'm unclear if that's pages only, or actual blocks too? Sitemap is around 2,000, but there alot of non-pubic pages as well that are not counted in that.
• No links available yet. Set to launch first subSite anytime, but wanted to get this taken care of first so several related subsites could use the theme (and work) yet have their own logos, navs, etc. I'll PM you once live.
• Performance:
—For sub-sites using purchased themes, excellent! Page loads in under 3 seconds.
—For the primary site that I built myself on bootstrap 2.3.2 to get the whole thing migrated to c5, Horrible. Page load takes about 8 seconds on first load. In defense of c5 and speed issues, I've custom made many c5 themes over the years, and many were slow. I now know this is mostly MY fault. Too much CSS, too much bloat, just trying to do too much and thus, too many http requests that slow it all up. Just goes to show that all the issues with web (responsive, speed, SEO) we make ourselves. Just plain semantic HTML works perfectly, everywhere. Everything else is just candy that designers and devs need to be stay vigilant on and keep as small a footprint as possible.
• User Management:
I use group sets to define some broad things, like access to sitemap and file manager for almost everyone. Then I make groups as needed and add them to the appropriate group set for basic system access stuff. I take the approach of treating everyone like adults so they act like it and take site editing seriously. If anyone runs afoul, they're out, and that position's responsibilities require WorkFlow to allow future publishing until trust is rebuilt. Works good.
Best thing I did was customize the WYSWIG to only include what I wanted for editors to produce semantic HTML. The less needed the better. Absolutely no font for font color choices allowed. Everything works mostly via the tags and styles drop-downs and that's how I train. I also added in ABBR for abbreviations. We have alot of them, and I train everyone to use ABBR tags heavily b/c it's great keywording opportunity.
• Other Thoughts: Love c5 b/c it's allowed me to grow as a developer, manage a large site and empower others to help it grow much larger. Maintenance is still easy, even though the site doubled in size over year's time, the maintenance aspect is the same for me
And that's a wrap!
Cheers!
Pat.
By education I come from a design background and have learned PHP somewhat along the way. I'm no noob to PHP, but earlier felt as if I was missing some key aspect of c5 that could be leveraged here to do the job easily.
I'm happy to say:
1) I've become a better programmer than I thought
2) c5 has everything I need to keep the job simple
3) I've gotten even deeper into c5 than ever before, and still find it a delight :)
Ultimately what I've ended up doing was:
A) Already was using config/site_theme_paths.php file for various custom c5 single_pages like login, 404, etc. Using that file that's already being loaded by the dispatcher, I've setup some theme detection that should be really extendable in the future:
$v = View::getInstance(); $theme = $v->getThemeHandle(); #echo $theme; //useful if you need to get the theme_handle really quick if($theme == 'theme_karma') { include(DIR_BASE . '/tools/department_theme_check.php'); }
This allows me to extend any theme the way I need via c5 dispatcher by adding theme detection and including my detection tool, department_theme_check.php:
global $c; $nh = Loader::helper('navigation'); $cobj = $nh->getTrailToCollection($c); $rcobj = array_reverse($cobj); /** * List of sub-site we need to check for. * Add more as needed via cID */ /** SHS Sites using Karma Theme (School of Heath Sciences) */ $subSite1 = '3980';// sub site #1's home page's cID $subSite1Home = '382';//sub site #1's parent page $subSite2 = '1965';// sub site #2 cID, etc. //add more as needed if(is_object($rcobj[1])) { //Home Page loaded as an object //Loop thru the array
Viewing 15 lines of 28 lines. View entire code block.
This gives me a variable for each theme to detect by.
Then, in my theme file, I can call the site_theme_paths.php, which calls the theme detection tool above and gives me theme variables to work with in the theme itself. Effectively allowing me to setup custom global stacks for thinks like logo, nav, footer using 1 theme, with easy variety.
<header> <?php if (file_exists(DIR_CONFIG_SITE . '/site_theme_paths.php')) { @include(DIR_CONFIG_SITE . '/site_theme_paths.php'); } if($department === 'Sub Site #1 Dept.') { $a = new GlobalArea('Logo_SubSite_'.$theme.'_theme'); $a->display(); } ?> </header> <nav> wash and repeat...
Is this the right way to do this? No idea. Probably not. I'm hoping the community can help refine it. But as it, it works for my purposes very elegantly (I think).
In response to your other questions:
• Site size, going by cID number only is approaching 5,000. I'm unclear if that's pages only, or actual blocks too? Sitemap is around 2,000, but there alot of non-pubic pages as well that are not counted in that.
• No links available yet. Set to launch first subSite anytime, but wanted to get this taken care of first so several related subsites could use the theme (and work) yet have their own logos, navs, etc. I'll PM you once live.
• Performance:
—For sub-sites using purchased themes, excellent! Page loads in under 3 seconds.
—For the primary site that I built myself on bootstrap 2.3.2 to get the whole thing migrated to c5, Horrible. Page load takes about 8 seconds on first load. In defense of c5 and speed issues, I've custom made many c5 themes over the years, and many were slow. I now know this is mostly MY fault. Too much CSS, too much bloat, just trying to do too much and thus, too many http requests that slow it all up. Just goes to show that all the issues with web (responsive, speed, SEO) we make ourselves. Just plain semantic HTML works perfectly, everywhere. Everything else is just candy that designers and devs need to be stay vigilant on and keep as small a footprint as possible.
• User Management:
I use group sets to define some broad things, like access to sitemap and file manager for almost everyone. Then I make groups as needed and add them to the appropriate group set for basic system access stuff. I take the approach of treating everyone like adults so they act like it and take site editing seriously. If anyone runs afoul, they're out, and that position's responsibilities require WorkFlow to allow future publishing until trust is rebuilt. Works good.
Best thing I did was customize the WYSWIG to only include what I wanted for editors to produce semantic HTML. The less needed the better. Absolutely no font for font color choices allowed. Everything works mostly via the tags and styles drop-downs and that's how I train. I also added in ABBR for abbreviations. We have alot of them, and I train everyone to use ABBR tags heavily b/c it's great keywording opportunity.
• Other Thoughts: Love c5 b/c it's allowed me to grow as a developer, manage a large site and empower others to help it grow much larger. Maintenance is still easy, even though the site doubled in size over year's time, the maintenance aspect is the same for me
And that's a wrap!
Cheers!
Pat.
Thank you for writing about your experience, PatrickHenry.
Hearing about large scale/enterprise scenarios is always interesting and useful.
Hearing about large scale/enterprise scenarios is always interesting and useful.
Sure! c5 is great b/c it's empowered me to empower my editors to really expand the website with great content. c5's Editing Interface is perfect and requires little training to get going. Once editors start making stuff, I come in and show them how to fine-tune it. Works great.
A big help was being able to run all our event calendars through google calendars. This handles lots of little do-dad events that only have a name, location, time & date, and a sentence of description.
Then for more full-fledged events, we use ProEvents and they get their own page in the system. These are "Featured Events" we can easily port to the homepage so it's always got fresh content. Paired with ProBlog, this works great.
I've noticed once the site was setup, 80% of the new content added is either an event or a news post of some sort. This fact makes managing editors easier b/c alot of times, they just need to be able to create events or posts.
Overall, it's working well. Thanks for your interest!
Feel free to PM me if you'd like to know how I've tackled anything.
A big help was being able to run all our event calendars through google calendars. This handles lots of little do-dad events that only have a name, location, time & date, and a sentence of description.
Then for more full-fledged events, we use ProEvents and they get their own page in the system. These are "Featured Events" we can easily port to the homepage so it's always got fresh content. Paired with ProBlog, this works great.
I've noticed once the site was setup, 80% of the new content added is either an event or a news post of some sort. This fact makes managing editors easier b/c alot of times, they just need to be able to create events or posts.
Overall, it's working well. Thanks for your interest!
Feel free to PM me if you'd like to know how I've tackled anything.
I'm thinking something like:
1) get Art page's page ID and path
2) Get current page path
3) detect by URL string if the page is a child?
— it'd be better if I could detect this by cID instead, since path's aren't always reliable if it's an alias or something?
Not sure, just thinking out loud.
Anyone got a better idea, or a nice way to go about it this way?