Doesn't work with WP Super Cache enabled by scribu · Pull Request #164 · wp-cli/wp-cli

scribu · 2012-12-04T12:42:58Z

I just set up wp-cli version a45bfd0. If I run it from outside my wordpress installation, it correctly prompts me to prove the --path argument. If I run wp --version, I see wp-cli 0.7.0-alpha, so that looks good. However, if I run any other command, either from the WP install folder, or by providing --path pointing to it, all I see is the HTML of my homepage.

Have I just misconfigured something?

scribu · 2012-09-14T10:10:55Z

Are you sure it's the html of your homepage or a warning that WP isn't installed or something like that?

pkaeding · 2012-09-14T15:09:14Z

No, it is my homepage content. I saved it to a file and opened it in a browser to be sure it wasn't just my site's chrome wrapping an error message or something, but it is actually just the HTML from my home page.

scribu · 2012-09-14T15:15:34Z

That's weird. Do you have any caching plugins active, like WP Super Cache?

pkaeding · 2012-09-14T15:38:06Z

Yes, as a matter of fact, I do use WP Super Cache. Is this what is causing the problem?

scribu · 2012-09-14T16:03:52Z

Only way to find out is by removing it, particularly the files in wp-content.

pkaeding · 2012-09-14T16:52:50Z

Okay, WP Super Cache seems to be involved. I disabled the cache, and then wp help returned the expected output.

I don't want to disable the cache, though. I guess I could disable the cache before using wp-cli, and re-enable it afterwards, but that sucks.

Is it possible to have wp-cli not get cached responses?

pkaeding · 2012-09-15T04:28:56Z

Wow, after having just upgraded the core WP code, and a handful of plugins in under 2 minutes (including toggling WP Super Cache off & on), this is amazing! Upgrades have always been a bit of a pain, since I don't like the idea of making the WP installation writable by the user that it runs as.

While I still think it would be great if we could get wp-cli and wp super cache to play well together, this is still an amazing tool! Thanks!

andreascreten · 2012-11-06T13:46:54Z

I did some tests with WP Super Cache and WP-CLI and for me everything works great. Can you send us some screenshots of your WP Super Cache settings?

pkaeding · 2012-11-09T05:05:22Z

Sure, here are are what seem to be the interesting parts of my WP Super Cache config screens: https://dl.dropbox.com/u/2397175/wpsupercache.pdf. I have the CDN options disabled, so I omitted that screen, but let me know if you want to see that, or anything else that might help.

Thanks!

getsource · 2012-11-27T22:09:15Z

Does it work any better if you change to using mod_rewrite to serve cached files?

markjaquith · 2012-11-30T20:40:43Z

I ran into similar problems with Batcache. Here was my solution:

In wp-config.php, instead of blindly defining WP_CACHE, make sure we're not running on the command line:

if( !defined( 'WP_CACHE' ) && PHP_SAPI !== 'cli' )
    define( 'WP_CACHE', true );

markjaquith · 2012-11-30T22:24:06Z

Two options that I see:

WP-CLI could define WP_CACHE as false
Individuals could use my snippet to not set WP_CACHE when on the command line

scribu · 2012-12-01T12:32:02Z

WP-CLI could define WP_CACHE as false

I don't see how. Whether it does it before or after wp-config.php is loaded, they'll get a "constant is already defined" error.

Similar problem with WP_DEBUG: #177

markjaquith · 2012-12-01T12:35:19Z

But isn't that just a warning? Not the end of the world...

scribu · 2012-12-01T22:12:10Z

Not the end of the world, but definitely annoying if you have WP_DEBUG on, as any development install should have.

markjaquith · 2012-12-01T22:31:17Z

Ah yeah. So, then I'd recommend option 2: that people add that simple PHP_SAPI !== 'cli' check before defining WP_CACHE. I'm trying to think of a way that WP-CLI could help guide people to that solution...

scribu · 2012-12-01T22:38:25Z

Another solution would be to move the PHP_SAPI !== 'cli' check into Core, before loading wp-content/advanced-cache.php.

scribu · 2012-12-02T18:49:24Z

http://core.trac.wordpress.org/ticket/22683

getsource · 2012-12-03T23:13:03Z

The only concern I have about the "let's rely on others or core to set WP_CACHE to false" approach is that part of the primary purpose of wp-cli is the upgrade both plugins and core. In these cases, wp-cli will fail to upgrade, and will never get to the point where it will work without manual intervention.

Perhaps we could provide a flag to force it, with the foreknowledge that it will toss a warning if it fails?
It is still an option to force the define via a config file including PHP, but that's a bit of a significant workaround.

markjaquith · 2012-12-03T23:44:12Z

What about tricking WordPress into thinking that WP-CLI runs are is_admin()? All caching backends I know of bail for that.

scribu · 2012-12-04T11:26:30Z

That could work.

scribu · 2012-12-04T12:44:39Z

f28cdcc seems to do the trick.

Doesn't work with WP Super Cache enabled

getsource · 2012-12-04T18:27:15Z

Nice!

Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped. 1. Provides a way of forcefully bypassing wp_maintenance(). 2. Provides a way of forcefully bypassing wp_debug_mode(). See wp-cli/wp-cli#177 3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See wp-cli/wp-cli#164 These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress. See #34936. Props jorbin, DrewAPicture. Built from https://develop.svn.wordpress.org/trunk@37626 git-svn-id: http://core.svn.wordpress.org/trunk@37594 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped. 1. Provides a way of forcefully bypassing wp_maintenance(). 2. Provides a way of forcefully bypassing wp_debug_mode(). See wp-cli/wp-cli#177 3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See wp-cli/wp-cli#164 These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress. See #34936. Props jorbin, DrewAPicture. Built from https://develop.svn.wordpress.org/trunk@37626

Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped. 1. Provides a way of forcefully bypassing wp_maintenance(). 2. Provides a way of forcefully bypassing wp_debug_mode(). See wp-cli/wp-cli#177 3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See wp-cli/wp-cli#164 These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress. See #34936. Props jorbin, DrewAPicture. git-svn-id: https://develop.svn.wordpress.org@37626 602fd350-edb4-49c9-b593-d223f7449a82

Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped. 1. Provides a way of forcefully bypassing wp_maintenance(). 2. Provides a way of forcefully bypassing wp_debug_mode(). See wp-cli/wp-cli#177 3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See wp-cli/wp-cli#164 These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress. See #34936. Props jorbin, DrewAPicture. git-svn-id: https://develop.svn.wordpress.org/trunk@37626 602fd350-edb4-49c9-b593-d223f7449a82

pretend we're in /wp-admin/

f28cdcc

scribu pushed a commit that referenced this pull request Dec 4, 2012

Merge pull request #164 from wp-cli/fix-164

40c9256

Doesn't work with WP Super Cache enabled

scribu merged commit 40c9256 into master Dec 4, 2012

scribu added a commit that referenced this pull request Dec 30, 2012

never load advanced-cache.php. see #164

8f3b660

scribu mentioned this pull request Mar 10, 2013

Add flag to treat command as not WP_ADMIN. #351

Closed

scribu mentioned this pull request Apr 19, 2013

--context flag for determining the context in which WordPress is loaded #385

Closed

scribu mentioned this pull request Aug 23, 2013

Loading issue related to W3 Total Cache #721

Closed

Conversation

scribu commented Dec 4, 2012

Uh oh!

scribu commented Sep 14, 2012

Uh oh!

pkaeding commented Sep 14, 2012

Uh oh!

scribu commented Sep 14, 2012

Uh oh!

pkaeding commented Sep 14, 2012

Uh oh!

scribu commented Sep 14, 2012

Uh oh!

pkaeding commented Sep 14, 2012

Uh oh!

pkaeding commented Sep 15, 2012

Uh oh!

andreascreten commented Nov 6, 2012

Uh oh!

pkaeding commented Nov 9, 2012

Uh oh!

getsource commented Nov 27, 2012

Uh oh!

markjaquith commented Nov 30, 2012

Uh oh!

markjaquith commented Nov 30, 2012

Uh oh!

scribu commented Dec 1, 2012

Uh oh!

markjaquith commented Dec 1, 2012

Uh oh!

scribu commented Dec 1, 2012

Uh oh!

markjaquith commented Dec 1, 2012

Uh oh!

scribu commented Dec 1, 2012

Uh oh!

scribu commented Dec 2, 2012

Uh oh!

getsource commented Dec 3, 2012

Uh oh!

markjaquith commented Dec 3, 2012

Uh oh!

scribu commented Dec 4, 2012

Uh oh!

scribu commented Dec 4, 2012

Uh oh!

getsource commented Dec 4, 2012

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants