Using roots without less / or how you make LESS more user friendly

I build around 20 websites basing on roots - but only one using less… I understand idea, and when i’m coding it from scratch it;s quiet cool - but the problem starts when you start showing website to client…
mostly - you need 5 second change in style every few hours - that’s how most of clients give me feedback… and here problem start - coz u need to start whole Apache, database etc… the bigest problem is when i’m not in office and i want to ask somebody to change one value - that’s painful…

how you work with it?

You could always setup (1) a temporary CSS file for quick client mods; or (2) a custom field in the WP backend for custom CSS that gets output in your <head> to override your main.css.

Am I missing something here?

  1. Why would a change in a *.less file require a restart of anything at all?
  2. Why would you be making changes directly on what is essentially a staging/testing machine?

I think you may need to take a hard look at your workflow and process here. I would strongly suggest you develop and code on one machine/instance. Once the changes are completed and tested a simple ‘grunt build’ and push to your staging/testing environment takes only seconds.

Personally I use a shell script to both 1) call ‘grunt build’ then 2) rsync to my customer facing test machine. There are a number of tutorials on even including the push to staging within your grunt file via rsync, ssh, even ftp; but to be honest I’ve not jumped in to grunt with both feet since a 2 line shell script works for me.

1 Like

Why would a change in a *.less file require a restart of anything at all?

I thought that originally too, but if your server environment isn’t always powered up then it seems pretty irresponsible to run Grunt and push something untested to a client facing staging server without testing it locally first, hence the need to power up your local environment. I suppose it’s a personal matter of whether you’re willing to gamble with client facing assets; I am not.

Absolutely, that’s why I’d never suggest that.

I spent too many years in operations/service delivery to even consider it.

1 Like

My recommendation is not to Cowboy Code. Your clients should understand that you don’t push things up without testing them first, because you care about the quality of your work before it’s on the web.

Thanks all…

So in summary - When I start working with it - I’m customising all less values - so configure what’s possible there.

It’s generating me my main.min.css,

after getting what i can from predefined values I start adding my ones in app.less file… so you are suggesting not to work with my extra classes in this file? just crate new css file and add extra things there? then it’s not optimized - and i can work with online file

  1. Why would a change in a *.less file require a restart of anything at all?

when i got website installed on server - client is working on content on-line, when i want to add styling to something he done i will need:

  • start my local apache
  • start grunt
  • sometimes download modified database and files (re-import database etc.)

…and from one simple change - which on standard css file will took me 1min - i lost 15min…

so my question is - how make this things work better? when i install website on-line - it’s live, and want to work on less files with content which was added after development - how you working with that?

Is your client installing new plugins or are they entering custom HTML and styling in posts/pages?

Yes sometimes we’re adding new plugins on online version - he’s adding new content etc.

Sounds like you’re dealing with what I consider to be WordPress’s strongest and weakest feature, and yes they are one in the same. By that I mean the ability of a site owner/administrator’s to install plugins, modify underlying CSS, and manually add styling to any post or page. All of which can totally wreck a very carefully and skillfully crafted website design in seconds.

As long as your client can write content or install plugins you’ll have to deal with this in some form or fashion. But an important thing to remember is that these types of changes shouldn’t fall under your support agreement for your initial design of the website. If you have a separate maintenance agreement then you should cover them there. The bottom line here is that you cannot code/design a website that will work well with every single plugin or hand coded styles that someone may enter into a post or page.

If you have a maintenance agreement with the client, or if you have a client who ‘knows just enough to be dangerous’ I’d recommend that you keep a staging/testing server active and online. Even go so far as to give the client WordPress administrative privileges on that instance. Strongly encourage them to use this instance to test new plugins or site changes before they commit them to production.

This allows them to tinker without hosing up the production site and it allows you to mange your time and client expectations more effectively. But the primary benefit is to allow you some control over site changes and provide a testing/staging environment for you deploy and test your tweaks.

I keep this environments online and accessible 24/7 so that a client can always ‘play’ and I can test and deploy changes in short order if needed. With that environment in place there is no restart of a server at all, no starting or stopping of services. In this day and age these types of instances, either virtual or shared are dirt cheap; so take advantage of them.

But again, as I said in an earlier post; the managing of deployments to either staging/testing or production is relatively simple with the tools already available with Roots or Bedrock. Take advantage of the tools at your disposal and make your life easier.

1 Like

How you dealing with database changes? You always need to download database and replace your local one?

Generally speaking I don’t often keep the staging environment content in sync with the production environment. If I actually need the full content (database) from production I’ll do a simple MySQL backup on production and restore it on to staging. Just update a few URL settings in wp_options and and you’re good to go.

In most cases I don’t see a real need to keep the content synced at all.

OTHER problem is adding plugins - when client start working on content - want me to add new one, i’m adding it in local one - to style it - and i need to do same on online version… i don’t see any option here to do it better? or again install online and download database?

just this simple things - when i’m not working with less making some troubles with it - I just don’t like to loose time for so small things :slight_smile:

Keeping everything in a good git workflow might be really helpful for you - if the client adds a plugin you can do a commit and then pull things down to your local environment.

Check out bedrock, because a lot of your questions could be answered there.

For DB syncing, there are LOTS of options out there, but I particularly love Migrate DB Pro, it’s just SO easy to keep things synced up.