search

WordPress / meta-environment

A collection of scripts that provision the official WordPress.org websites into a Varying Vagrant Vagrants installation.
190 stars 69 forks source link

Multiple site errors: `404 not found` (with a new fresh install) #67

Closed ntwb closed 8 years ago

ntwb commented 8 years ago

The translate.wordpressorg.dev will be covered in #54

The above is from a brand new VVV & WME install, I've not yet been able to narrow down the root cause, will continue to poke around.

ocean90 commented 8 years ago
iandunn commented 8 years ago

I didn't get any 404s, but I did get quite a few other errors.

@ntwb, if you're still seeing the 404s, can you run vagrant provision 2>&1 | tee wme-provision.log and copy the output to a Gist?

ntwb commented 8 years ago

plan.wordcamp.dev - I'm not sure was it removed from the db, but it was probably by accident. That's ok, though, because it's not being used anymore on production. That content was migrated to the handbooks on make/Community, so we can just remove the link in the wp-meta.dev dashboard

👍 Fix is in #70

The ../../ might be throwing it off, or maybe just the change to loading it from the meta-repository Git checkout.

I'd have loved to have done this, but I want to be able to commit to meta.svn as needed from within VVV the meta environment, hence the switch to Git wasn't an option 😞

if you're still seeing the 404s, can you run vagrant provision 2>&1 | tee wme-provision.log and copy the output to a Gist?

Done -> https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc

ntwb commented 8 years ago

FWIW, everything under www/wordpress-meta-environment/meta-repository/wordpress.org/public_html/wp-content looks correct, plugins, themes, translations, mu-plugins...

Ahhh... But there is no WordPress at: www/wordpress-meta-environment/meta-repository/wordpress.org/public_html/

It should be located in: www/wordpress-meta-environment/meta-repository/wordpress.org/public_html/wordpress

ntwb commented 8 years ago

There's half a dozen of these errors:

==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path=`path/to/wordpress` or run `wp core download`.

https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L308 https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L309 https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L397 https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L399 https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L505 https://gist.github.com/ntwb/6a374e9b44072b286e35a4c5a81ee4bc#file-wme-provision-log-L507

So two sites only include /wordpress

And fives sites do not:

So the culprit appears to be wp core download --version=nightly --path=$SITE_DIR/wordpress as wp core download --path=$SITE_DIR/wordpress --allow-root works fine for the two sites that use it.

grappler commented 8 years ago

FYI wp core download --version=nightly I think only working in WP-CLI 0.24.0.

ntwb commented 8 years ago

FYI wp core download --version=nightly I think only working in WP-CLI 0.24.0.

Yes, I think that is the case, checking wp --version results in WP-CLI 0.25.0-alpha

I'll continue to investigate further in the morning

iandunn commented 8 years ago

I think @grappler meant that it's only available since 0.24.0, not that it was added in 0.24.0, and then removed in 0.25.0. It's still there in the master branch and I can run it in 0.25.0.

VVV updates WP-CLI to the master branch during the provision process, and that should happen before the vvv-init.sh scripts are called.

Maybe the problem is the lack of the --allow-root parameter? We had to add that in #6, but at the time I thought it was only a safety measure for older VVV installs. I could have been wrong, though; we have had some permission issues related to WP-CLI lately in #48 and #53.

ntwb commented 8 years ago

Right, will play around with adding --allow-root in a bit 👍

In the meantime, manually copying the /wordpress folder from the buddypressorg.dev site to the wordpressorg.dev site appears to fix the core of the problem, WordPress is now available, that said, new errors for some sub sites now exist:

iandunn commented 8 years ago

@ntwb, I was able to reproduce it and 5b2c796 fixes it for me. Would you mind verifying that it's fixed for you too?

ntwb commented 8 years ago

All good @iandunn, working as expected 👍

Updated VVV and WME Repos locally:

==> default: # Updating jobs.wordpressnet.dev
==> default: #
==> default: From git://meta.git.wordpress.org
==> default:  * branch            master     -> FETCH_HEAD
==> default: Already up-to-date.
==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path=`path/to/wordpress` or run `wp core download`.
==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path=`path/to/wordpress` or run `wp core download`.
==> default: # Updating wordpresstv.dev
==> default: #
==> default: From git://meta.git.wordpress.org
==> default:  * branch            master     -> FETCH_HEAD
==> default: Already up-to-date.
==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path=`path/to/wordpress` or run `wp core download`.
==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path=`path/to/wordpress` or run `wp core download`.

Which seems right, both sites already exist, but due to previous original issues can't be updated, deleting the sites and re-provisioning should resolve these.

Deleting both sites above fixed these, working as expected.

(The same "should" have occured for wordpressorg.dev but didn't as I manually rebuilt this site so I could get work done.)

iandunn commented 8 years ago

Awesome, thanks :)