• Code organization. This is the main benefit. It drops the classic WP theme format for a more modern MVC paradigm. If used properly, all of your logic is included in controller files, and all of your markup is included in view files, and there's little to no overlap. The JS organization is also real nice, but in my experience most WP devs are lovely JS devs, so this may or may not be of value to most folks.
  
• The Blade template engine is helpful, but not really necessary imo. You can entirely ignore it if you want, and just write straight PHP in your views. But it's handy if you want to avoid filling your markup with <?php ?>
  
• Cache busting built in by default. When you yarn build:production your files, it automatically hashes filenames for your dist directory, so you never run into the whole, "I'm not seeing the change," / "omg clear your cache" dilemma with clients.
  
• Webpack/browser sync built in, real nice for dev.
  
• Easy to add in NPM packages as necessary since the project is built with the Yarn package manager as its backbone.
  
• Third party documentation. This is a huge plus if someone besides you will ever touch the code. I've dealt with way too many entirely bespoke themes in my life (including those that I've made), so when it comes time for me to exit a project it's wonderful to be able to put this in the readme.md: "This project is built on Sage[link], please refer to their documentation if you have any questions."
  

• Lots of bugs in the most recent versions. Version 10 is not production ready (despite what the Roots forums say), and has a lot of really obnoxious bugs. Even the latest version 9 branch has some pretty huge problems (for example, if you reference an image in your SASS the compiler won't be able to find and will refuse to compile due to dependency conflicts), so I'm still using 9.0.9 on all of my projects.
  
• Reliant on a lot of NPM dependencies that are now significantly out of date. Version 10 in theory solves this, but again, it's not ready for prime time.
  
• It is very opinionated, which is really both a pro and a con. JS/SASS linting is enabled by default with some very strict rules. Function names must follow a very particular format (camel-casing) in your controllers, otherwise they just plain won't work. This helps keep things organized, but especially when you first start working with it there will be times when you just need something to work and instead you end up banging your head against a wall for an hour before you realize you needed to use $my_var instead of $myVar.
  
• Not at all newbie / junior dev friendly. It's really tailored for hardcore PHP devs.
  

pipebomb fucked around with this message at 23:41 on Mar 1, 2022

https://oldurl.com/  ==>  https://newurl.com/
then
https://oldurl.com ==> https://newurl.com
then
oldurl.com/ ==> newurl.com/
then
oldurl.com ==> newurl.com

kedo fucked around with this message at 18:24 on Mar 23, 2022

$array = array(
    'url' => 'https://www.example.com',
    'something_else' => 'foobar'
);
echo serialize( $array ); // a:2:{s:3:"url";s:23:"https://www.example.com";s:14:"something_else";s:6:"foobar";}

kedo fucked around with this message at 16:03 on Mar 25, 2022

let val = parseInt( $('.field1').val() );
if ( val >= 500 ) {
	$('.field2').val( 500 );
} else {
	$('.field2').val( val );
}

kedo fucked around with this message at 15:44 on Mar 28, 2022

GRECOROMANGRABASS fucked around with this message at 20:35 on May 6, 2022