Sage is a productivity-driven WordPress starter theme with a modern development workflow.

Hello! I really like Roots and would love to tinker around but Ive gotten a small problem at hands. I have a fresh WP 3.3.2 installation and latest Roots cloned from here but after installation, it does not find the CSS and JS files declared in head.

I am not sure what the issue could be but Im sure Im not the only one. Anyone has any helpful information?

I've been using this theme to design and deploy sites for about 4 months and I love it. But recently I've been running into the following problem. Has anyone else had this problem.

My environment:

• WP 3.2.1
• Live server: hosted with Hostmonster.com
• Roots theme version: 3.6.0
• Other plugins: A couple plugins I've written for Custom Post Types, Custom Meta Boxes, & Custom Taxonomies. (no rewrite rules, filters, or remove actions being used.), & plugin to change from email address (uses filter for wp_mail_from & wp_mail_from_name).

Description: I install & activate the theme and it loads fine. After I've been customizing it, making changes to template files, function.php, and/or editing plugin files... I'll get a 500 server error. When I check my error logs on the server I see rewrite rules errors. So I check my htaccess file. This is when I see that it was rewritten, and the code is either jumbled thereby causing an error, or it has appended or prepended additional code that causes errors. Here's the latest code that was added to the end of the htaccess file.

This code was added after the # END Wordpress ------ Code Starts Here --------- ue error_prepend_string " "

/# Don't prepend to error (doesn't accept empty string, use whitespace if you need) /# php_value error_append_string " "

/# Increase cookie security php_value session.cookie_httponly true /# END WordPress ------- Code Ends Here ---------

Note: After I removed these lines, the site came back up. This keeps happening, sometimes every few hours, sometimes every few days. Any suggestions would be greatly appreciated.

Mark.

Hi, The new re-write for script URLs for example seems to be killing some plugins - for example, the output looks like:

<script src="/base//base/wp-content/plugins/jquery-colorbox/js/jquery.colorbox-min.js"></script>

Also - why wouldn't this be hooking into the proper re-write to not only be relative, but also use the /plugins URL as it did in other versions? /base is the root of the site -- in a sub-directory and /base is also the name of the theme folder

Also, when adding in new scripts the standard WP way, this doesn't work properly:

function roots_custom_scripts() {
  wp_register_script('roots_script_less', THEME_PATH . '/js/less.min.js', false, null, false);
  wp_enqueue_script('roots_script_less');
}

add_action('wp_print_scripts', 'roots_custom_scripts');

It spits out <script type='text/javascript' src='/basewp-content/themes/base/js/less.min.js'></script> which is missing a / and also is not rewritten. If we are trying to take the approach of not touching the core roots files, then what's the best way to add JS files? Maybe a quick WIKI addition would help, but something seems a bit off with the plugin rewrite for JS files in general unless I'm missing something. Thanks.

I've been trying to create a child theme in my wordpress which is installed in a custom directory (/vendor/wp in my case) and configured to work by default from / .

In the functions roots_scripts() in roots-scripts.php the value of $base is right, but it seems that the function wp_register_script adds automatically the base wordpress directory and hence duplicates the first part of the URI, in my case it converts it to /vendor/wp/vendor/wp/wp-content/themes/roots/js/[...]

I'm not enough familiar with the URI functions of wordpress, but it seems that is necessary a function like get_template_directory_uri() but relative to the install directory of wordpress.

By now I'll bypass the value of $base in the parent theme.

Thanks for a wonderful product.

Regards from Spain.

The ideal version of this PR replaces Sage's _wp-classes.scss but the reality is a bit more complicated. Note that this PR brings the total build:production up to 229kb. If you compare that with the Gutenberg default styles, I believe it is a net savings.

I tried to adhere to Bootstrap standards as much as possible but it has been a couple years since I have used this framework. I imagine that there are more bootstrap-y ways to do many things within this PR, and I think it's probably best if someone who is already opinionated about usage of Bootstrap to incorporate them. I have tried to structure my work in a way that will make that process approachable.

Note that this PR also includes an additional composer dependency: querypath/querypath. It is utilized in filters.php to wrap .alignwide and .alignfull blocks using a div with the class .gutenberg-wrap applied. This makes it much easier to deal with these elements.

This analysis / study, along with many, many hours of frustrating experimentation, have led me to believe this is the correct approach. Also note the adoption of this method by Gutenberg contributor Chris Van Patten. To me, this component of the PR serves as a reasonably lightweight fix for an issue in a very unpredictable upstream.

This PR also restructures the starter template so that Gutenberg can have the full viewport. While it is possible to have Gutenberg output restricted to a container with a width less than 100vw there are issues that crop up when dealing with .alignwide and .alignfull elements. The main solution I've seen has been to utilize something like this:

.entry-content .alignfull,
.entry-content .alignwide {
    margin-left: calc( -100vw / 2 + 100% / 2 );
    margin-right: calc( -100vw / 2 + 100% / 2 );
    max-width: 100vw;
}

This works pretty well but it is not 💯. As detailed in the codepen.io study above, this approach causes issues with wp-block-cover that have a fixed background on various mobile devices. This is why I believe the approach in this PR is something closer to a best practice and am utilizing it in my own projects.

There are still some missing pieces of functionality, but this PR is already rather broad and I do not want to FUBAR it with complexity.

when activating roots you should be asked if you want everything in roots-activation.php to take place (rather than being forced):

• create home page
• create nav menus and set their locations
• add all pages to primary nav
• set permalink structure to /%year%/%postname%/
• set uploads folder to /assets/ and don't organize by month/year

when twitter's bootstrap 2 comes out on january 31st we should make it the default CSS framework

http://www.markdotto.com/2012/01/24/bootstrap-2-ready-for-testing-and-feedback/

• [x] Add Bower (#922, #978)
• [x] Better LESS organization (#961)
• [x] Different Grunt workflow (#933)
• [x] Leaner Roots (#992) — clean up, relative URLs, and nice search moved to Soil
• [x] Update screenshot to 880x660 (maybe just use a blank image)
• [ ] Merge in @Foxaii's nav rejig
• [x] Move language files outside repo
• [x] Add grunt-autoprefixer
• [ ] Setup dist/ folder?
• [x] Generate new roots.pot
• [x] Update CHANGELOG
• [x] Update README
• [x] Update roots.io docs

What's new

Leaner Roots

Soil will now be a plugin that contains:

• Markup changes/clean up
  • wp_head() clean up
  • Remove WP version from RSS feeds
  • Clean up <html> attributes
  • Clean up <link> tags
  • Clean up body_class()
  • Wrap embedded media as suggested by Readability
  • Use <figure> and <figcaption> for WP captions
  • Remove unnecessary dashboard widgets
  • Remove unnecessary self-closing tags
• Nice search
• Relative URLs

The above features will be enabled in Roots (or any other theme) if Soil is activated by using add_theme_support:

• add_theme_support('soil-clean-up');
• add_theme_support('soil-nice-search');
• add_theme_support('soil-root-relative-urls');

Removed from Roots:

• lib/cleanup.php - Move roots_get_search_form to lib/utils.php
• lib/widgets.php - Remove vCard widget, move register sidebars to lib/init.php
• lib/relative-urls.php

Bower for front-end package management

Bower is now being used to pull in Modernizr, jQuery, Bootstrap and Respond to assets/vendor/. Whenever you're adding front-end assets to your project, you can use bower install <package> to add them to the vendor directory.

We're also now using grunt-modernizr to make a lean build based on what tests you use in your styles and JS.

If you check out the 7.0.0 branch, run npm install from the theme dir and bower install will run after the node dependencies have been installed.

LESS organization

LESS files are organized differently, see #961 for details. tl;dr:

├── components
│   ├── _buttons.less
│   ├── _forms.less
│   ├── _media.less
│   └── _wp-classes.less
├── layouts
│   │── pages
│   │   └── _home.less
│   │── _footer.less
│   │── _general.less
│   │── _header.less
│   │── _pages.less
│   │── _posts.less
│   └── _sidebar.less
├── _bootstrap.less
├── _global.less
├── _variables.less
└── main.less

Grunt workflow

Previously, every time you updated your CSS or JS, a minified files and changes to lib/scripts.php had to be committed to the repo. The repo no longer includes any generated front-end assets. Grunt tasks are now split into two: dev and build.

The dev task runs JSHint, compiles your LESS (non-minified) and concatenates your JS

The build task runs JSHint, compiles and minifies your LESS, runs UglifyJS for concatenation and minification, generates a lean Modernizr build, and revisions CSS and JS based on the hashes.

During build, assets-manifest.json is generated with the names of the revisioned files. lib/scripts.php reads that file and tells WordPress the correct path to the assets.

Testing

Check out the 7.0.0 branch and run npm install from the theme directory. If you don't use Bedrock, you'll need to add the following to your wp-config.php:

define('WP_ENV', 'development');

Grunt tasks:

• grunt dev
• grunt watch (same as dev except watches for file changes)
• grunt build — for staging/production

Also grab https://github.com/roots/soil's new branch and enable the plugin

Note: things are subject to change!

These changes are not yet final. Keep an eye on this PR for updates.

Cleaner walker moved to a Soil module: https://github.com/roots/soil/pull/73 (it no longer includes support for Bootstrap dropdowns)

Remove the Bootstrap navbar and use a more generic header template (remember, this is a starter theme (and we're becoming framework agnostic))

When I've moved WP to a remote server (as shown here), put it on an own directory (not on the server root -- eg: http://example.com/wordpress instead of http://example.com) and let this option at config.php enabled:

add_theme_support('root-relative-urls');

Roots broken CSS, JS and other stuff, such as admin bar. For example, the call to the /wp-includes folder was http://localhost/wp-includes (should point the "wordpress" folder). This bug also have affected bloginfo('template_url') -- the function doesn't display anything. Reactivate Roots didn't work.

Nevertheless, when I was running WP in my computer, everything was working fine... even with WP on a subdirectory (http://localhost/wordpress).

BTW, this is a wonderful theme! Nice work! :)

In a lot of my projects I've started using an alternative to get_template_part that allows you to pass data. I'm wondering whether something of this ilk would be good to include with Sage.

Function

/**
 * Load a component into a template while supplying data.
 *
 * @param string $slug The slug name for the generic template.
 * @param array $params An associated array of data that will be extracted into the templates scope
 * @param bool $output Whether to output component or return as string.
 * @return string
 */
function get_component($slug, array $params = array(), $output = true) {
    if(!$output) ob_start();
    $template_file = locate_template("components/{$slug}.php", false, false);
    extract($params, EXTR_SKIP);
    require($template_file);
    if(!$output) return ob_get_clean();
}

This PR contains the following updates:

| Package | Type | Update | Change | |---|---|---|---| | aglipanci/laravel-pint-action | action | major | 1.0.0 -> 2.1.0 |

Release Notes

Configuration

📅 Schedule: Branch creation - "before 3am on Monday" in timezone America/Chicago, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

The following <nav> elements need accessible names (i.e. can be set with aria-label or aria-labelledby).

• resources/views/partials/content-page.blade.php
• resources/views/partials/content-single.blade.php
• resources/views/partials/comments.blade.php

Possible solutions

Use aria-label to set accessible names for these regions. Do not use the word “navigation” in the name (it’s redundant).

References

• https://w3c.github.io/aria-practices/#aria_lh_navigation
• https://www.scottohara.me/blog/2018/03/03/landmarks.html#navigation

Steps To Reproduce

1. This is the current state of the templates.

Expected Behavior

When there’s more than one navigation region on a page, they should have accessible names to distinguish them from each other.

Actual Behavior

These unnamed navigation regions might appear more prominent than they should be.

Relevant Log Output

No response

Versions

HEAD

In development, CSS is injected and not included via a file. To be able to use correctly some JS functions that depend on style (el.scrollWidth, etc.), we have to wait until the CSS is injected and parsed.

Some development environments such as Valet use .test, but some others such as Localwp use .local Adding an .env file to set the proxy to use in bud config can be helpful when working with other developers who using different development environments.

These changes are required to upgrade to Acorn v3

TODOs

• [ ] Acorn v3 stable release
• [ ] Upgrade docs (https://github.com/roots/docs/issues/433)
• [ ] bud.sage.setAcornVersion('v3')

Ref https://github.com/roots/acorn/releases Ref https://bud.js.org/releases/6.6.0/#rootssage

The yarn command was not able to really create a complete pot file. Most strings from the Blade templates were missing. With this command, it seems to be working as it should be.

I found the command in the docs https://docs.roots.io/sage/10.x/localization/#generating-language-files

I removed the previous command to avoid any misunderstanding.