Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accommodate child themes: Update WP stylesheet_root separately #850

Merged
merged 2 commits into from
Jul 25, 2017

Conversation

fullyint
Copy link
Contributor

@fullyint fullyint commented Jul 21, 2017

This PR is a piece of the former #848 and addresses https://discourse.roots.io/t/template-root-not-updated-by-env/9724

When a child theme is in Bedrock web/app/themes and its parent theme is in different directory (e.g., web/wp/wp-content/themes), stylesheet_root must be /themes while template_root should be updated with the latest deploy releases_path. Prior to this commit, stylesheet_root was always updated with template_root, causing problems for some child themes.


Regarding the regex_replace: Till now Trellis has assumed that if a template_rootincludes the releases path (e.g., /srv/www/example.com/releases) then we can replace the entire template_root using the new release path + /web/wp/wp-content/themes. Maybe that's a safe assumption, but at my level of familiarity, the only thing I feel safe saying is that "I know the release path portion can be replaced with the new release path, but I don't know about the rest of the path."

That's why you'll notice that I made the following replacement (pseudo code):

- wp option set {{ <option> }} {{ deploy_helper.new_release_path }}/web/wp/wp-content/themes
+ wp option set {{ <option> }} <old_full_path> | regex_replace(releases_path + '/[^/]+(.*)', new_release_path + '\1')

The only weakness I can think of for this change is that it is less readable. Maybe someone who knows more will say that the original assumption was safe, implying that this change is unnecessary.

When a child theme is in Bedrock `web/app/themes` and its parent
theme is in different directory (e.g., `web/wp/wp-content/themes`),
stylesheet_root must be `/themes` while template_root should be
updated with the latest deploy releases_path. Prior to this PR,
stylesheet_root was always updated with template_root, causing
problems for some child themes.
@fullyint fullyint force-pushed the update-stylesheet-root-separately branch from af9df8d to b9f449c Compare July 21, 2017 20:32
command: wp option set {{ item }} {{ deploy_helper.new_release_path }}/web/wp/wp-content/themes
command: >
wp option set {{ item.item }}
{{ item.stdout | regex_replace(deploy_helper.releases_path + '/[^/]+(.*)', deploy_helper.new_release_path + '\1') }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using deploy_helper.previous_release_path and just replace with deploy_helper.new_release_path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured users could have template_root values with release paths different from previous_release_path but that still needed to be replaced. One example might be if a user imports a DB from staging where the previous_release_path was different than here in production. Or, perhaps the prior release was failed and template_root never updated but deploy helper has that failed path as previous_release_path? I didn't test if this latter could happen.

Copy link
Member

@swalkinshaw swalkinshaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@fullyint fullyint merged commit d926dbb into master Jul 25, 2017
@fullyint fullyint deleted the update-stylesheet-root-separately branch July 25, 2017 02:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants