Edit: I’m using concrete 8.5.2 and really don’t want to update yet.
I duplicated the default elemental theme and put it in application/themes/custom and got it all working by following this guide: How to copy the Elemental theme to use as a base for new themes
It works but when I, for example, duplicate right_sidebar.php and rename it to a new template name, I go into page templates and add it, and it works, but it looks into concrete/themes/elemental for the php file, and since I made the new theme file in application/theme/custom, it can’t find it and instead uses default.php from the concrete/theme/elemental folder.
I’ve been trying for hours, using chatgpt, scouring the forums, scouring google, and I can’t for the life of me find the code that controls what folder the theme (or concrete 5) uses to decide where to look for page template php files.
If I edit header.php in the custom theme folder, that works and updates and applies to all pages, but the page templates and their data are being pulled from the old elemental folder. Please tell me someone knows where the deciding code is located so I can change the directory.
Alright so I got an update. I tried changing the namespace and get theme name declaration in page_theme.php in the concrete/themes/elemental folder.
After doing this, Concrete5 started ignoring that and instead used page_theme.php from the correct folder, application\themes\custom folder. After that, it broke the website permanently. Even after reverting the files, now I get the following error on all pages:
Whoops \ Exception \ ErrorException (E_COMPILE_ERROR)
Cannot declare class Application\Themes\PageTheme, because the name is already in use
The only way around this, is I have to remove or rename page_theme.php in both application/themes/custom as well as concrete/themes/elemental. If i put page_theme.php back into either folder I get this error. So I was able to get the website usable for the public again by renaming both of those for now, but I can’t add new pages to the website without them.
I tried changing a million different things in the following code but to no avail:
> namespace Application\Themes\Custom;
> use Concrete\Core\Area\Layout\Preset\Provider\ThemeProviderInterface;
> use Concrete\Core\Page\Theme\Theme;
> class PageTheme extends Theme implements ThemeProviderInterface
Specifically the website hones on on that last line of code as the problem when I put it back in. If I change “pageTheme” in that code to “kladjlaskdjlkas” then I get the exact same error but then it will say that kladjlaskdjlkas is already in use.
My website is permanently broken until someone can help me understand how to fix this or where to even look. I tried poking around some in src/theme/theme.php but to no avail, I’ll try looking again, I’m hoping it’s not some kind of database bug. If anyone can give literally any input at all, it would be very helpful.
Try changing Themes to Theme (Singular not Plural)
Thank you, so here’s the next update. If I change the namespace to have theme singular then it works again and I can edit the website again, but here’s where it gets insane. Now that I used theme singular once and hit save in the file editor, now I can change it to themes plural and that works too, but only after having changed it to theme singular once.
Now I’m still back to the original problem. So I have the following areas in the file manager.
I’m using the custom theme, when I make a new page type in the “custom” directory (right_sidebar2.php for example) then I go to the page templates section of themes in the editor I can activate the theme. After activating it, it uses default.php from the elemental folder because even though it detected the new php file in custom, and that’s what I used to activate a new page template, after I do that, it looks inside the elemental folder for the php file when deciding what to use for the template when I actually go to use it.
Can anybody help me figure out how to fix this? I’ve spent two whole days now reading through files, forums, playing with chatgpt, reading documentation, etc.
You could try my free package Elemental Cloner. It lets you make a copy of elemental either in the application folder or a package and gives you a few options to customize it. I never had a complaint so I guess it might help you.
You can find it here:
Thank **** for you and this. Doing it manually is a broken buggy mess. The elemental cloner worked, thank you. So last update about it before I used the extension. I tried installing another copy of the elemental theme that I named “good” and after I did that things got even more insane.
Then when I made a copy of a php file in the “good” theme I couldn’t activate it in the good theme in the editor. When I made a copy of a php file in the “custom” theme I could only activate it from the elemental theme’s page templates section. But then when I went to use it, it would look into the elemental theme’s folder for the php file when actually going to use it on a page.
Also I tried renaming the custom folder, which broke it permanently even after reverting the change. Then after I added that “good” theme I just talked about, that magically fixed the “custom” theme I made. That crap is extremely unstable and bug ridden. I hope somebody comes onto this thread someday to explain what the problems might have been, but for now I used the elemental cloner and it just works, so I’m using it and moving on, I’ve already lost way too much time/money by wasting 2 full work days on this.
Update again. So the elemental cloner did work, I added a new page template and it worked. Now I came back a few hours later and tried to add another new page template and now it’s looking in concrete\themes\elemental again for the php files after I set them up. Does anyone know how to fix this and make it look in the correct directory for the page template php files?
Shot in the dark… does your host have some sort of caching system? I have sites on SiteGround and it’s infuriating to have to keep going to their Panel and clearing their caches. I finally added some lines to my .htaccess file that turns most of them off but there are still times when I need go and clear the ‘Dynamic’ cache to get the system to grab the new files.
Also, I’d remove ALL the failed clones that you made, turn off all caching inside concretecms, delete everything in the application/files/cache folder (leaving an empty cache folder). I’d even go so far as to remove all the failed clones PLUS the clone that the Elemental Cloner created and start with a clean slate.
Okay I tried a lot of that, but it seems this it isn’t a caching problem. Upon further testing, it’s isolated to custom template php files. So if I make a custom theme and edit its default templates, like right sidebar and left sidebar, those go through and it’s pulling data from those files. But if I make a custom php file in the folder and then activate it in the theme, that’s when it looks into the original elemental theme directory.
I tried deleting every cache I could find, but it really doesn’t seem like a caching problem. The problem is somewhere in the code, it only looks into the original folder for the custom theme php files. The originals, it looks into the new folder.
So I think I’ve isolated this some more, but this is shocking to me. Has nobody in the entire concrete5 community ever duplicated a theme and then added a custom page template??? Like this is crazy to me that after multiple days nobody’s chimed in who knows what’s happening. Is this truly an isolated problem? I can’t help but start to suspect that 99% of developers have never duplicated a theme and then went on to add custom php theme files.
The editor simply does not look into application\themes when doing a lot of stuff. If I get rid of page_theme.php from elemental then the website still works, but when I go to make a page it says there’s no grid framework because the editor by default does not look into application like everyone says.
I’ve seen everywhere, everyone says to duplicate a theme into application before editing it so you don’t lose your changes when you update concrete5, but now I’m starting to think that all the people who suggest that haven’t actually done any theme customizations ever and didn’t realize it still looks into the concrete directory for a ton of the theme files.
If I rename concrete\themes\elemental to something else, i.e. concrete\themes\elemental2 then the website still works but when I go to make a page it can’t find any templates so I can’t edit the website.
If you zip up your custom theme and email it to me, I will load it into a sandbox install and test it for you.
So, I think this is actually a loooooong standing problem where Page Templates from old, retired, deleted themes are shown but since these themes are no longer available (or even on the server), the system defaults to default.php. Here’s the code that retrieves the Page Templates to be displayed in the list of templates.
public static function getList($includeInternal = false)
$em = \ORM::entityManager();
$args = ['pTemplateIsInternal' => $includeInternal];
$list = $em->getRepository('\Concrete\Core\Entity\Page\Template')->findBy(
$args, ['pTemplateID' => 'asc']
$list = self::sort($list);
As you can see, it SORTS the page templates by pTemplateID but does not FILTER out page templates that do not exist in the active theme. As far as I can see from looking at the tables, there is no easy way to actually tell what templates belong to which theme. I recall living with this ‘problem’ since, well, forever. I have come to the conclusion that there must be some reason why the system needs to show ‘deprecated’ page templates but for the life of me, I can’t think of one.
Anyone with more intimate knowledge, please chime in.
I can do that if you want, not sure if there are dm’s on the forums but I can send it to you if you want.
This seems like more on the right track of the problem. This is what I was worried about, that it’s actually just a bug with no solution. Now I’m starting to think if I can instead workaround this by building all my themes in right sidebar.php and attempting to use a switch-like system based on the url of a page. At least if I know there’s no fix for the bug I can then start spending my time making a workaround.
An alternate approach.
Build your custom theme with the same area names as Atomik (or Elemental) or a super-set of those names. Same for page templates.
For page specific variations within those templates, use containers.
Since V9 and containers, I find I have considerably less use for special to purpose page templates because containers can be used to create variations within existing templates.
I recall many years ago, I installed about 15 themes into a test site and by the time I was done building additional template files (to learn how things worked), there were over 30 ‘dead’ template files in the system and most of them ended up rendering with the default.php because they didn’t actually exist. That’s when I knew something was seriously messed up. The tables that contain these page templates have a field called ‘pkgID’ which might be able to specify what templates go with what theme but the value for pkgID is always ‘0’ so that’s not very helpful.