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

Add asset cache version helper function. #585

Closed
wants to merge 4 commits into from

Conversation

kopepasah
Copy link
Member

This helper function will use filemtime while using WP_DEBUG for development and Gutenberg's version for package releases.

@aduth
Copy link
Member

aduth commented May 1, 2017

Remarking from #440 as it relates to the changes here:

One final consideration is should we implement the filemtime with WP_DEBUG or SCRIPT_DEBUG/STYLE_DEBUG?

Per documentation, it sounds like SCRIPT_DEBUG might be the more appropriate (or more specific anyways) constant.

index.php Outdated
$version = false;

if ( defined( 'WP_DEBUG' ) && WP_DEBUG && $file ) {
if ( file_exists( plugin_dir_path( __FILE__ ) . $file ) ) {
Copy link
Member

Choose a reason for hiding this comment

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

Nice addition of the file_exists. I think I'd seen some discussion where this was previously logging a warning if the file didn't exist.

index.php Outdated
$version = $plugin['Version'];
}
} else {
$version = false;
Copy link
Member

Choose a reason for hiding this comment

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

It doesn't seem to follow that $value could be anything other than $false at this point (except manual tampering of the transient). Do we need to assign this?

Copy link
Member

Choose a reason for hiding this comment

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

And if we do eliminate the else, we could probably collapse the function_exists check into the ! $version condition to bump down the indentation one.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are correct. Originally I had set the transient outside the brackets and forgot to remove after moving.

index.php Outdated
if ( function_exists( 'get_plugin_data' ) ) {
$plugin = get_plugin_data( __FILE__, false );

if ( isset( $plugin['Version'] ) ) {
Copy link
Member

Choose a reason for hiding this comment

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

In my testing, it appears the Version key will always be set in the return value from get_plugin_data, but could be empty. Therefore we'll probably want ! empty instead of isset here.

Copy link
Member Author

Choose a reason for hiding this comment

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

! empty sound like a good addition.

@kopepasah
Copy link
Member Author

@aduth I pushed up a few changes to address your comments.

@aduth
Copy link
Member

aduth commented May 1, 2017

@kopepasah I'm not seeing any changes. Did you forget to push?

index.php Outdated
$version = $plugin['Version'];
}

set_transient( 'gutenberg_version', $version, DAY_IN_SECONDS );
Copy link
Member

Choose a reason for hiding this comment

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

With the logic here, if the version is not assigned, we'll perform a get_transient and set_transient on every request. I think we'll either want to:

  • Only set_transient if Version is not empty (move into condition above)
  • Allow transient to be set to an empty string, but strictly check this before calling get_plugin_data

My preference is toward the second, which is a matter of changing ! $version to false === $version to reflect we only want the condition to match if get_transient returns it's empty state, but not for the empty string.

If the transient does not exist, does not have a value, or has expired, then get_transient will return false.

https://codex.wordpress.org/Function_Reference/get_transient

Practically speaking, we know that the version will be assigned (it already is), but if we were so confident, we'd also not need the ! empty( $plugin['Version'] ) check. So one way or another, we should be consistent.

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree the second option is probably best and being more explicit by using false === $version is a good idea; however, allowing an empty value (while it may never be empty in this case) would not be ideal if we want the transient to update if the value were to return not empty (after set as empty).

How about something like:

if ( false === $version && function_exists( 'get_plugin_data' ) ) {
	$plugin = get_plugin_data( __FILE__, false );

	if ( ! empty( $plugin['Version'] ) ) {
		$version = $plugin['Version'];

		set_transient( 'gutenberg_version', $version, DAY_IN_SECONDS );
	}
}

@nylen
Copy link
Member

nylen commented May 1, 2017

How do we ensure that the stored version transient will be invalidated on plugin upgrade (or install/reinstall)? I think that needs to be done here.

@aduth
Copy link
Member

aduth commented May 1, 2017

How do we ensure that the stored version transient will be invalidated on plugin upgrade (or install/reinstall)? I think that needs to be done here.

At that point, I wonder if it's all worth pulling, caching, and invalidating the plugin metadata vs. just define-ing a constant, even if it's duplicated.

@kopepasah
Copy link
Member Author

How do we ensure that the stored version transient will be invalidated on plugin upgrade (or install/reinstall)?

We should implement activate/deactivate hooks to set the plugin version.

At that point, I wonder if it's all worth pulling, caching, and invalidating the plugin metadata vs. just define-ing a constant, even if it's duplicated.

While I typically do not like defining constants for version numbers, I agree it might be worth considering in this case.

@westonruter
Copy link
Member

We should implement activate/deactivate hooks to set the plugin version.

Such hooks can be considered harmful. See WordPress/WordPress-Coding-Standards#881 (comment)

@kopepasah
Copy link
Member Author

@westonruter thanks for pointing that out.

At this point I would say it is probably best to use a constant for the version number.

@mtias mtias added the Framework Issues related to broader framework topics, especially as it relates to javascript label May 3, 2017
@nylen
Copy link
Member

nylen commented Jun 12, 2017

At this point I would say it is probably best to use a constant for the version number.

This was implemented in #1025 as part of the plugin zip build process. This PR can be simplified significantly as a result: use the GUTENBERG_VERSION constant if it is defined, otherwise use filemtime.

gziolo
gziolo previously requested changes Sep 22, 2017
Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

There was no activity for a quite some time and now the changed file is conflicting. @kopepasah, do you plan to resolve those conflicts and address all above comments?

@nylen
Copy link
Member

nylen commented Sep 23, 2017

This was superseded by #1025.

@nylen nylen closed this Sep 23, 2017
@nylen
Copy link
Member

nylen commented Sep 23, 2017

Never mind. I should have read the comments including my latest more carefully :)

@nylen nylen reopened this Sep 23, 2017
@kopepasah
Copy link
Member Author

Sorry, have been away. I can resolve these changes in the next 24 hours.

@kopepasah
Copy link
Member Author

After review, I can see now that filemtime is used in many areas for enqueuing scripts from client-assets.php. In addition, there is information in docs/blocks-stylesheet.md which mentions using filemtime as how to add the version of the stylesheet.

Before I make all of these updates, are we certain we want to use GUTENBERG_VERSION as the scripts and stylesheet version?

@gziolo gziolo dismissed their stale review September 25, 2017 10:17

Not familiar with this part of Gutenberg.

@gziolo
Copy link
Member

gziolo commented Sep 25, 2017

@pento can you help with a review here or help find someone else?

@gziolo gziolo requested a review from pento September 25, 2017 10:18
@kopepasah
Copy link
Member Author

@pento I am happy to make the changes, but want to verify just to make sure we are going this route before spending the time.

@codecov
Copy link

codecov bot commented Sep 25, 2017

Codecov Report

Merging #585 into master will increase coverage by 0.03%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #585      +/-   ##
==========================================
+ Coverage   33.69%   33.72%   +0.03%     
==========================================
  Files         185      191       +6     
  Lines        5594     5903     +309     
  Branches      976     1043      +67     
==========================================
+ Hits         1885     1991     +106     
- Misses       3141     3308     +167     
- Partials      568      604      +36
Impacted Files Coverage Δ
editor/sidebar/post-schedule/index.js 63.15% <0%> (-1.85%) ⬇️
editor/inserter/index.js 0% <0%> (ø) ⬆️
editor/modes/visual-editor/index.js 0% <0%> (ø) ⬆️
editor/modes/visual-editor/block-list.js 0% <0%> (ø) ⬆️
editor/document-outline/item.js 0% <0%> (ø)
editor/document-outline/index.js 0% <0%> (ø)
editor/sidebar/document-outline-panel/index.js 0% <0%> (ø)
editor/modes/visual-editor/inserter.js 100% <0%> (ø)
editor/table-of-contents/index.js 0% <0%> (ø)
editor/word-count/index.js 0% <0%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 26369c3...4714c93. Read the comment docs.

@pento
Copy link
Member

pento commented Sep 26, 2017

So, GUTENBERG_VERSION would be the ideal option for this, but it seems like it's only available in the release version of Gutenberg, which isn't so ideal. :-)

I'm pondering if we should modify gutenberg.php to set the version to the current git commit, that'll be replaced with the proper version number during the release process. Ie, something like:

define( 'GUTENBERG_VERSION', trim( shell_exec( 'git rev-parse HEAD' ) ) );

@nylen
Copy link
Member

nylen commented Sep 26, 2017

Wouldn't it be better to use a function which returns the mtime in development mode? Otherwise things may be cached in between commits.

@pento
Copy link
Member

pento commented Sep 26, 2017

A function seems like a bit of overkill, and I'm not wild about the pattern of writing out the filename twice.

Also, if you're actively editing code, your dev environment should either be not caching, or responding with an appropriate ETag or Last-Modified header for cache invalidation.

@nylen
Copy link
Member

nylen commented Sep 26, 2017

your dev environment should either be not caching, or responding with an appropriate ETag or Last-Modified header for cache invalidation.

The reasoning behind using filemtime is that in practice this will often not be the case, and we should ensure that dev environments behave predictably anyway.

Edit: The above is just to explain the reasoning behind the existing decision. I won't be working on this further and don't have a strong opinion about the best way forward.

@staylor
Copy link

staylor commented Nov 3, 2017

This PR has zero changes - close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants