Concrete CMS tries its best to keep its styles from conflicting with those in themes. For example, all of the Concrete custom editing CSS is prefixed with the div.ccm-ui rule, meaning that it will only take effect if the tags exist within a tag that has the class ccm-ui. Unfortunately, some themes are not quite so thoughtful. If you’re building HTML yourself from scratch you can take care to not have collisions with Concrete core styles. If you’re picking up HTML off the shelf from a theme website as we’ve done here, you may need to clean up some greedy stylesheets. This is a good skill to have when doing Concrete theme development.
In this case, I already have a strong sense of what the culprit is: Font Awesome. Font Awesome. Font Awesome is a great way to add a lot of rich icons to your website, and we use it for the core Elemental theme. Lots of third party themes do, as well. Unfortunately, if the version bundled with your theme doesn’t match the one included with the Concrete core, you may have issues with collisions. In this case, my thought is that the Font Awesome version bundled with the Dreamrs theme doesn’t have some of the icons that the Concrete core needs -- and some of the icons may have changed, as well.
Let’s look at the HTML source of the website and look in the <head> area, because that’s where our Font Awesome CSS is going to be loaded.
I see a potential problem here.
We’re loading Font Awesome twice. The first is coming from the Concrete core; the second is coming from the theme. The core loads Font Awesome here because it needs to display the icons in the editing toolbar. The theme loads it because it’s hard-coded in the header of theme (and the theme presumably needs it for its own purposes.)
Let’s fix this problem; first, let’s see what this looks like if we use the theme’s version of Font Awesome, and stop the core from loading its own copy. To do this, we need to tell Concrete that our theme provides a copy of Font Awesome, so that it won’t load its own copy. To do this, we use the providesAsset() method within our Concrete\Package\Dreamrs\Theme\ThemeDreamrs\PageTheme class. Load that class, and lets add a method:
public function registerAssets()
{
$this->providesAsset('css', 'font-awesome’);
}
The registerAssets() method runs the moment the theme is registered in Concrete. It takes care of telling Concrete what assets the theme provides, as well as what core CSS and JavaScript assets the theme needs.
If we reload the page, we can see the result:
We’re now no longer loading the core concrete/css/font-awesome.css file, which is good. Unfortunately, things have gotten worse:
Now we’re missing even more icons. The version of Font Awesome shipping with the theme appears to be newer than the one that Concrete uses. This isn’t ideal, but we can work around it. Let’s switch gears here. Instead of using the version of Font Awesome provided with the theme, let’s remove the one provided by the theme, and use the one included with the core.
First, let’s go into our PageTheme class and change providesAsset() to requireAsset(). This will tell Concrete that our theme needs the Font Awesome asset provided by the core.
public function registerAssets()
{
$this->requireAsset('css', 'font-awesome');
}
Next, let’s go into header.php and remove the call to the Font Awesome that’s provided by the theme. Delete these lines:
We don’t need this, because the core will now provide Font Awesome. With these changes, let’s reload the browser and look at the source.
Notice the concrete/css/font-awesome.css call is back, and the call to the special Dreamrs fontawesome/css/all.min.css is gone. And if we check out page, we get a nice surprise:
Success! We’ve fixed the icon issue. An annoying one to be sure, but hopefully getting some experience with these types of issues will help you debugging theme conflicts in the future.
Now that we have a nice looking toolbar, let’s move on to adding our first editable area to the Full width template!