Hi @mesuva
Your tool sounds like an easy way to approach simple style changes to Atomik but what about font changes?
If using your tool, I add a font override for Atomik won’t concretecms then still load the original font into memory?
Just thinking of efficiency issues.
regards
alex
@mesuva Hi! Does that Theme Styling tool simply add a wrapper div for a page which you can style in the editor? How does it resolve ‘!important’ settings for the items inside?
Hi,
I try to follow the new documentation but I’m stuck at this step : Setup Development Environment :: Concrete CMS
I write the command “npm run production” all seems good but the folder “js” and the file main.js are created in my theme but all repertory are created. Only the css folder and the file main.css works normally.
And this is my folders and files in my new theme. Totally insane why it works well for the main.css but not for the main.js?
Before that I followed all the steps describe in this documentation Create and Install a Basic, Empty Theme :: Concrete CMS
I create a new folder “theme_bedrock_documentation” outside of my website folder. (Should this be put in a special place?)
I have node_modules and all files required.
This my my command in the file package.json, is there a problem?
{
"dependencies": {
"@concretecms/bedrock": "^0.9.3",
"laravel-mix": "^6.0.42"
},
"scripts": {
"development": "mix",
"watch": "mix watch",
"watch-poll": "mix watch -- --watch-options-poll=1000",
"hot": "mix watch --hot",
"production": "mix --production"
},
"devDependencies": {
"resolve-url-loader": "^5.0.0",
"sass": "^1.49.7",
"sass-loader": "^12.6.0",
"webpack-cli": "^4.9.2"
}
}
And my webpack.mix.js
let mix = require('laravel-mix');
mix.webpackConfig({
externals: {
jquery: 'jQuery',
bootstrap: true,
vue: 'Vue',
moment: 'moment'
}
});
mix.setPublicPath('/Users/tacktack/Documents/Sites/Hésingue/site/mairie_hesingue/public/application/themes/mairie_hesingue');
mix
.sass('assets/scss/main.scss', 'css/main.css')
.js('assets/js/main.js', 'js/main.js');
Thank you for your precious help
Brice
@alexwag - that’s a really good point, yes, the theme styling tool is really just a way to inject another stylesheet, so it’s not going unload fonts that are loaded in.
In Atomik the fonts are loaded in via the active Skin (‘preset’), so it might be possible to create just a new skin for the theme, and adjust the fonts that are loaded there, rather than having to clone the entire theme.
I’ve had a quick try of this via the /application folder, and was able to drop in a new preset there and change the font.
The issue I’m seeing with that approach though is that it then tries to load main.js from the application folder (as I think Concrete sees the base of the theme now being in /application). Perhaps there’s a better way to add custom presets, something to investigate further.
@linuxoid - the theme stying tool doesn’t add any wrappers to the page, it simply links in another stylesheet that you can enter the contents of using the pop-up editor. That stylesheet is linked in after your theme’s styles (if the theme is built correctly), meaning that it should allow you to override CSS styles that have !important on them.
The same ‘specificity’ rules apply, as if you were just appending more CSS to the bottom of the main stylesheet. !important rules can be overridden by further !important rules if they come later. Hopefully there aren’t many uses of !important in Atomik though!
My great disappointment with the whole v9 theme infrastructure is there is very little use of css variables. Yes, the skins generate big files of css variables, but they are not respected universally throughout the rest of the theme css. Andrew informs me that some of this comes from the underlying Bootstrap not using css variables.
Whatever the reasons, shared between Atomik and Bootstrap, if css variables were used throughout, many developers currently struggling to setup environments to recompile the entire theme could simply override some css variables.
A massively missed opportunity.
My steps simply work. It’s pain the *** but they do what I need and I have a theme similar to Atomik with some modifications. The greater the choice the better. My way is just one of many.
@JohntheFish I still maintain that Bootstrap isn’t actually a good base for building websites in general. I’ve always seen it as a toolkit to build interfaces rather than public sites.
I think it was just the first framework to really get prominent, and then many people adopted it for all purposes. I know now it’s pitched as being a framework to build anything, but I’m pretty sure it wasn’t intended to be that initially, it was for prototyping and quickly building interfaces.
The times I’ve had to use it to built a front-end theme, I’ve found it big and bloated, and difficult at times to override. It feels rigid. It’s better now in version 5 with its variable use, but it’s still huge. When I use it for management systems, I end up commenting out whole sections, as by default it includes a huge amount of stuff.
I do understand though why it’s used as a base here for the default theme, that’s still logical to me, it’s kind of the lowest common denominator, and then developers know what classes they should add to their HTML. So I don’t even think it’s the way it’s been used to create Atomik, it’s just the nature of bootstrap.
V9 theming for us though hasn’t really changed at all though. It keeps being repeated here on the forums that it’s all changed, but we’re able to just copy our v8 themes into v9 and they work fine.
We’re continuing to use our V8 ‘startpoint’ theme as a styling base, which is really just some layouts, boilerplate sass and a handful of custom templates, and we use that to built out a new theme. Often I’ll roll out a new site in the morning, and by the afternoon Lelita already has it looking 95% like a design. We don’t necessarily support every block initially, but if we do need to support something it’s really not a big deal to add a bit more styling.
I know we’re not the only way to work this way as well, I’ve seen others take similar kinds of skeleton themes, and use them as a base to build up completely custom themes, and it works well for them.
The next time I update our startpoint it might be worthwhile for me to do a video on it, to show how we approach things.
It’s really about coming at theming from two different directions:
The counter intuitive thing we’ve found is that it’s often more work to take an existing theme and try to morph it into a desired appearance, than it is to just built it from our startpoint. That might be because the sites we build often have completely customised appearances though.
I’m not saying there’s a wrong way to build V9 themes, I’m certainly not saying cloning Atomik and using it as a base is wrong - but I think it’s important to stress that it’s certainly not the only way to approach customising a theme based on Atomik, and may in cases be overkill, especially for those that are just wanting to change a few aspects.
PS - I’ve very liberal with how that Theme Styling Tool is used. Whilst it’s nice to get a few sales here and there for it, if people want to use it, test it out, etc, I’m happy to flick them copies, use it as much as they need across sites really.
On your 2 directions:
A) taking a complete theme, with all the bells and whistles, and customising it
B) starting from something very bare-bones, and building up a theme
Initially “Only a few small changes” 
- so start with A
Over time " Just another small change …" (repeat)
(many small changes later) - should have started with B 
Reflecting on marketplace themes customers have asked me to adapt, sometimes the ones that have turned out best to adapt are, completely counter-intuitively, the ones that have least commonality with the core. Kind of supports your first point.
Often the balance depends on how much custom edit dialogue and dashboard work is required. If there is a lot of such, keeping it all bootstrap for front end as well as back end can be convenient as there is no need to mentally juggle 2 frameworks.
@tacktack , I had exactly the same problem. The only way to solve it was to place the build folder next to the theme’s, that is:
application/themes/my_theme
application/themes/build
@mesuva , now that I figured out how to tackle the theme from one end (fast and least effort by cloning Atomik), I can now try from the other end making one from scratch (long and difficult based on Bedrock). And then compare which one is better in which case. Once good comprehensive documentation appears, it may be much easier to walk the same path. I just could’t get my head around the new scss approach until I’ve cloned, changed and compiled the Atomik clone. Now I’m ready for the Bedrock bare bones. 
As I see it, the difference with the two approaches (whether to clone Atomik or to start from Bedrock) is that:
Another insane aspect of v9 theme development has appeared.
I’ve just made 1 copy of the Atomik cloned theme. I have 2 folders on the server: the theme itself and the theme build folder. The latter is over 250 MB and has over 30,000 files because of the node modules.
I have 5 sites I have to support right now. And new ones are coming. Each site has its theme. I used to copy only the theme folder and changed that in v8. Do I now have to copy&paste the ridiculously huge build folder for each site on my server? If not on the server, then it’s another effort to copy the compiled assets to the server theme folders. This process is going insane. It’s another proof the development is not getting easier, quite the opposite. It’s becoming a big pain in the ***.
Any suggestions how to manage that madness of growing complexity and size?
@linuxoid Why are you pushing a build folder to a production server?
Does the theme work correctly with out the node modules folder, or the complete build folder?
I imagine the broader idea is that you build/compile your theme locally (or on a staging server), and only deploy to production the theme folder only.
@mesuva , No, not on production server, but on my local server. I’d never expect I had to keep gigabytes and millions of files on the server, even on local, even for development.
I imagine the broader idea is that you build/compile your theme locally (or on a staging server), and only deploy to production the theme folder only.
That’s exactly what I’m doing. But from small theme folders for v8 it all suddenly grew into that nightmarish monster in v9!
@linuxoid I reckon the size of the node_modules is going to be mostly dependencies that Bootstrap 5 needs, much more than what Atomik/Bedrock needs.
I’ve just taken a look at a project that isn’t Concrete, but compiles Bootstrap 5, and for that node_modules folder is about 220MB, for 29 thousand files.
So I think it’s just the nature of using Bootstrap 5, rather than Atomik.
It might be a case of just deleting node_modules once you’re done with compiling, and you just reinstall it when you need it.
You are running “npm install” inside “public/packages/atomik_theme_clone/build” folder, so it will create “node_modules”
at the same lavel
I would only run “npm install”/“npm run dev” from main app folder and set source/dist css/js paths there.
Though, I am not sure if it is possible right now with “atomik_clone” package without changing some paths in css/js files.
I am more a gulp-guy since a long time and have not been using webpack that much.
Million of files, yeah, welcome to npm:D.
Your “node_modules” is just in inconvenient place right now (for my taste at least).
Should have asked at the very beginning…
Are old (e.g. Elemental) themes still working in v9 with all their whistles and bangs from that time? All that LESS stuff like minimization, optimization, caching etc.?
Support for that has just been added back in to v9 on GitHub
@JohntheFish , so does that mean the less themes in v9 will work exactly the same as in v8 and scss theming with compiling is simply another option? I mean, will I have a choice whether to make a LESS or SCSS theme in v9.0.3?
This is a key question addressed to @andrew or the core team.
The Bedrock documentation says: «No, we’re not going to mandate that themes be built a certain way.»
Is that true?
–––––––––––––––––––––––––
Reason behind:
We have quite a few sites 5.6, 5.7 and newer to update. We wanted to wait until v.9 is ready. Reading this thread tells me that designers are forced to use LESS because Bedrock is too complex to handle for non programmers/developers. If LESS is phased out of v.9 would mean that we are in trouble explaining to our customers that we have to re-update the sites in a years or so. I don’t think any client would agree.
Therefore, this is an important question. Please confirm!
I expect there will be differences even for LESS based themes.
In principle, yes. The mechanisms are unlikely to be supported with enthusiasm as the core is firmly directed towards Bedrock.
Early in 5.7 there were attempts by package developers to integrate a SCSS or SASS compiler in the same way that the core integrated a LESS compiler. That would have provided a more developer friendly middle ground.
Unfortunately the php ported compilers for SASS/SCSS ran at <5% the speed of LESS and timed out for anything more than the most trivial code. Some of vendor code used was unsupported. The experiments failed and themes remained LESS until the arrival of Bedrock.
I have two client packages I’m working on locally that are modified 8.5.7 themes (php files) to work with 9.0.2 and PHP 8.0.8. For the time being everything is working perfectly. We have custom blocks, custom templates, a custom framework (no Bootstrap or Bedrock here thanks) and are still using less files.
We are not using ’Skins’, but we can still use the design buttons to change certain elements as before with an xml file. I’ve not tried using additional preset less files, only the ‘defaults’, don’t see why one or two more wouldn’t work.
If less support is removed I may have to try a less to scss convertor and fix what breaks or give up.