Previously I’d been Roots biggest fan but now I feel like the laughing stock - spending half my day debugging multiple points of failure to get a slider working.
On Roots you could just drop Javascript files straight in and they’d work, now I’m forced to use Bower which, while a potentially great idea, in practice is pretty awful.
This is what I’ve done this week:
Spent a day installing Owl Carousel only to realised that there were multiple problems with the Bower file (luckily there was a thread covering this else I’d never have got it working).
But now I’m just trying to get a lightbox working and MagnificPopup at first showed errors then suddenly didn’t but still didn’t work. Tried ColorBox and it just keeps showing errors in my Chrome console. In Dev terms there’s just way too many terms of failure - is it my JQuery, is it a bad Bower package, is it my setup of Sage? Frankly it’s ridiculous.
In comparison I’m building a Magento project which I quickly setup with Compass and all the above worked first time.
Basically because I’m not the boss of my company this is the last project I’ll ever use Sage on as we just can’t spend the time to spend a day getting a slider working!!! So I just wanted to vent here as - really - has no one else had these problems?
Were you able to figure out what the errors were? Colorbox comes with 5 examples, including the required CSS and images for each. They are not included with the bower.jsonmain declaration, so you would need to set up the overrides in your own Bower file to pull in the extra files you want to use.
Many Bower packages work without any extra intervention but there are ones that require you to set up overrides. However, in my experience, once you’ve learned how to do that, it makes the entire build process much more streamlined, not to mention the ability to upgrade all your frontend packages with a few terminal commands
Cheers for the replies. Feel free to delete this thread actually as my title is quite derogatory and shows a lack of respect to all the hard work you guys have done and how awesome Roots is and how much stuff it’s shown me.
Roots is about 50% of the reason I use Wordpress.
I basically wrote this at the moment of almost having a programming breakdown where I just couldn’t get anything working and was at one of those moments where I wanted to destroy my laptop and find an alternative career. I’m sure you’ve all been there.
A nights sleep, some meditation and resetting my project in Git to how it was before I stressed out and I got everything working within a few minutes!
I love the new Sage with SCSS and Gulp and a whole load of other stuff, but I really miss that I can’t just drag in javascript files to be compiled. I never used this in production on Roots but it was good for development if I wasn’t sure if Bower was working.
I’ve got some real problems with Bower. Like all the examples are like “and just type this and it works” where as in reality it doesn’t. Each Bower package doesn’t have a web page it just directs you to the official page for that project (where as it seems the people who’ve made the Bower packages aren’t always the people who’ve made the original JQuery library)
To me it reeks a bit of Window’s “installing executables off the internet” vs something community verified like Debian Package Manager.
Like Wordpress’s everyman-for-himself plugins, vs Drupal’s community verified modules.
I’m gonna sit down and spend a lot of hours learning more about Bower (though I’m not sure where from - probably just this forum really) as I really don’t understand a few things like how Sage pulls in JS but not CSS (therefore rendering obsolete any ease of upgrade)
That would be great Austin. The current documentation really implies that it’s all about Bower. The only other bit I see is links to the Asset Builder documentation but this is seriously in depth and is mostly complex code examples.
I’ve had a mess around with dropping JQuery libraries into the assets/scripts folder but they don’t seem to be being included. Would be great to have an example as there’s still lots of stuff that’s not on Bower
Also, talking of documentation, have you guys any thoughts on archiving documentation for older versions of Roots? Luckily I was working remotely on bad internet for a while so I saved most of your documentation for the Roots+Grunt starter theme. This has proved invaluable when i’ve had to check out some of my previous sites to make changes (and setup Grunt and the like).
@buswell I’ve been in similar situations to this with roots/sage before. I’ve come to the conclusion that for me professionally, where I’m doing about 80% simple front end development on brochure style Wordpress sites, that Sage isn’t for me.
The features I now look for in a theme are simplicity and something with an easy learning curve for other developers, especially those who are less keen to experiment and adopt new things like myself.
My objective was to create a skeleton for installing Wordpress with a blank theme, ready to go as a git project, as quickly as possible, and incorporate some of the excellent theme functions Roots has introduced.
I found that in a professional environment like mine, its very difficult to persuade less experienced devs of why they now need to learn a plethora of new techniques and technologies, just to build a theme. I find myself pretty stumped when trying to argue that its worth it.
I think of Roots/Sage as a fantastic tool for demonstrating how things can be taken to a next level, but I certainly think you need to consider which features are important to you and fine tune it to your needs.
If you’re interested have a look, it’s completely not intended for anything but my own personal use at the moment but I have considered getting it to a point where it could be shared, I’d love to collaborate if anyone else is in a similar boat.
p.s. should stress, I’m not knocking Sage, just saying I think there is demand for a totally blank theme, which sticks to some of the wordpress conventions that more ‘vanilla’ wordpress devs are familiar with (e.g. most function related stuff is just in functions.php, no theme wrapper, no bootstrap), but keeps as many of the workflow improvements as possible (Sass, JQuery CDN pre-built in).
People probably all have different needs in this regard, but junior dev friendliness is a big one for me.
Most other ‘starter’ themes I’ve followed seem to have a tendency to add more and more functionality and drift further and further away from their original stated plan of just being simple. I’m not sure that’s the main objective of Sage these days, or if it ever was.
I agree with this, definitely not. However I think its an understatement, there are other issues. For example, upon starting a Senior dev position with a company that specialises in building Wordpress themes and working with people who are very comfortable and experienced with the ‘wordpress way’ of theme building, I found Roots to be very unpopular with the dev team.
Whilst I appreciate most of the advantages Sage brings, in practice I found it really really difficult to convince people to make the switch. For example, is it really necessary to split functions.php up into 8 sub files and move them to a subdirectory when your functions.php is less than 150 lines in total? You’ll get devs who are familiar with looking in functions.php for everything complaining this is just confusing. So weigh up the time you save by being able to navigate your 150 lines a bit more easily against the time you waste explaining to everyone else that you’ve moved stuff around.
Maybe that’s not the best example, but hopefully gets what I mean across.
Or e.g. do you really need to be so hell bent on ‘Don’t Repeat Yourself’ style coding that you implement a custom theme wrapper for a site that only had 5 page templates anyway? Bearing in mind that every developer who works on it will first need to study how your custom theme wrapper works, which will be a trivial or potentially mind boggling task depending on their competence/experience.
Then there’s the OP’s frustration that things in Roots/Sage quite often change drastically from one version to the next.
I’m glad I didn’t fight too hard to get our business to start adopting Roots 7 as I’d have been resented by everyone when Sage 8 comes out and moves a lot of things around again.
I look at Sage as more of an enthusiast demo theme these days. It’s a good starting point if you want to look at how to integrate some more cutting edge stuff into a Wordpress theme, but I think it makes more sense to decide what’s actually of use to you, on a project by project basis. So I start with a blank theme and copy over certain features from Sage if I think they’re worth it, all things considered.
What they’ve achieved is still incredibly impressive.
I think if a company or a developer is serious about development, they should embrace 12 factor methodology or similar contemporary approaches and Roots provides this on Wordpress as much as it can. Other than this you can make it by your way which you feel good of course. In my opinion sage is not best tool for just building Wordpress themes, it’s best for making a complete web site with Bedrock-ansible and it should continue to be like this way.
I agree, I’m not arguing the case for Sage to be anything different, its a great working example of how to implement all this stuff, but I think there’s a time and a place for 12 factor methodology. Applying it blindly to every project you do just because the Sage devs told you to is really the wrong reason.
There is something to be said for following the path of least resistance in a professional environment.
It’s not an issue with Sage, its an issue with understanding your tools and knowing what is appropriate when.
“Does this actually save effort?” <- constantly ask yourself this
I have a seriously packed day so I regret that I can’t respond in-depth. But quickly:
This is where I need your help on the asset-builder repo. If you can’t figure out how to do something
Try one more time by reading the docs etc.
If you still cannot understand how to do something take note of where you got stuck
Make an issue: “I tried to do this but couldn’t figure out how to get it to work”. Include some discussion about your experience, what you tried, suggestions on how to make things more ergonomic for new people.
I can collaborate with you to fix it so issues like this don’t happen to anyone coming after you.
One important distinction here: all we are doing here with Roots is parroting what 99% of the world does outside of WordPress land. I use these patterns because they are proven.
I am constantly preaching this. You have to be very careful here. Recognize that the majority of the cost of a software project is maintenance (sourcesourcesource). Saving effort upfront is not always the ethical approach.
Is this really something that requires a lot of explanation? The functions file has a list of files to include at the very top of it, I have trouble understanding why this would be so hard to grokk for a group of people. This isn’t even really a Sage-specific thing, it’s a WP convention and I believe a fundamental misunderstanding that has been perpetuated. It has made for lazy developers or designers / do-it-yourselfers who didn’t know any better, copy-paste everything they find on stack overflow into one file until it balloons to 2000 lines. Just because people do it doesn’t make it correct.
And for reference, some of the other popular starter themes that are known to be more by the WP book also have functions in separate files, however I think they’re even more difficult to follow as functions and hooks seem to be everywhere:
I’ve used Roots/Sage quite happily on a single page site. I’ve also been in a similar position where as the senior developer at an agency, I brought the Roots/Sage workflows in with other developers who at first had a little trouble understanding it, but perhaps I was fortunate enough that they weren’t too lazy or scared of change that they allowed me to work through any initial misunderstandings and learning curves with them.
My point here is that Sage isn’t just for huge projects, I’ve used it on every type of site. Do I use it on small sites because I’m comfortable with it? Most likely. But that doesn’t mean it’s a bad fit for a small site. Heck, 5 page templates? That’s a lot IMO.
I suppose I don’t understand the argument. Is the theme wrapper necessary? Depends on your opinion, but in my opinion I would never go back to the “stock” WP way, for any size project. Is it hard to teach people what it does? Not really, in my experience. If you are all full-time at the same job, why couldn’t you take an hour and sit all the developers down and walk through what Sage does any why it’s good. Like Austin said, a little extra effort up front can save you a lot of time and hassle down the road.
This is definitely true, except that the OP’s specific use-case was one-and-done brochure-style websites. When an organization’s primary job is to churn out ten-page marketing sites, maintainability and code quality is unlikely to be their primary concern–mainly because these types of sites are rarely maintained beyond bugfixes within a few months of launch.
That said, the tools provided by Roots help raise the bar for WordPress development, and the concepts these tools help us to learn are well worth the initial time and effort. PHP developers get paid the least, and WordPress as a technology is dreaded the most by developers. I’d argue that upgrading your development workflow with more professional, modern tools (like those provided by Roots) enables us to do our part to change those statistics.
Point is: using these tools increases the quality, repeatability, and maintainability of our code and helps us develop WordPress sites like the rest of the world develops everything else. It also helps us learn new skills and principles that are portable to other technologies. In so doing, we can charge more, and turn WordPress development into something that’s somewhat more future-proof.
