Skeleton layout fundamentally broken. ABSPATH already set.

[crazyjaco]

Hello. I am trying to see if this box will work with my company's WordPress theme. I am using a Skeleton layout to abstract my content folder from core.

I am noticing the following lines in the wp-config.php in the www folder:

if ( ! defined( 'ABSPATH' ) ) {
    if ( 'standard' === BOX_DIRECTORY_LAYOUT ) {
        define( 'ABSPATH', dirname( __FILE__ ) . '/' );
    } else if ( 'skeleton' === BOX_DIRECTORY_LAYOUT ) {
        define( 'ABSPATH', dirname( __FILE__ ) . '/wp/' );
    }
}

Unfortunately, it will never enter this logic because ABSPATH will always be defined before the wp-config.php file is loaded. ABSPATH is set in the wp-load.php just before it then loads wp-config.php.

This means a skeleton layout will always break. :\

Even if I changed the above snippet to:

if ( 'skeleton' === BOX_DIRECTORY_LAYOUT ) {
        define( 'ABSPATH', dirname( __FILE__ ) . '/wp/' );
}

This wouldn't work either because then you are setting a constant twice, which will throw a php error.

There is no way to use a skeleton layout using a wp-config.php file within a separate wordpress install. The wp-config.php needs to be in a parent directory of core.

This a fundamental architecture problem and I'm not sure there is a quick solution, not having worked in this box for more than a few hours.

I get further by deleting all the wordpress files in the root of www except the wp-config files and navigating to my.hostname/wp, but then there is a problem in the wp-config.php trying to get the correct hostname.

[mikeschinkel]

@crazyjaco Thanks for the report. I will check on this in the next few hours and get back to you with a solution.

[crazyjaco]

still troubleshooting. I tried creating a HOSTNAME file in the root of the project but the code didn't seem to acknowledge it. since I'm using a skeleton layout, I changed the condition on line 4 of wp-config.php to

if ( getcwd()=='/var/www/wp' && isset( $_SERVER[ 'HTTP_HOST' ] ) ) {

That gets me the correct project wp-config-{host}.php file loading.

I'm breaking further along now, but it seems to be much further in the bootstrap.

[mikeschinkel]

@crazyjaco I am booting up a new setup to debug it now.

[mikeschinkel]

@crazyjaco BTW, I have worked on this to replace the rats nest that is typical wp-config.php configuration, but I had to task switch so did not complete all the issues. I will be able to complete it soon after which I'll tag it as 1.0:

https://github.com/wplib/better-wp-config

[crazyjaco]

Thanks Mike! Appreciate it. Sorry we didn't see you at WordCamp for Publishers in Chicago. ;) Hope you are well.

Thats an interesting repo. I'm going to have to give a closer look when I get a chance.

[mikeschinkel]

@crazyjaco I was working on a critical project and could not take the time away.

That said, I have decided to pull back from client work and focus 100% on (finally) getting the successor to WPLib Box out the door.

Have you signed up to our Slack? In case you have questions?

https://launchpass.com/wplib

[mikeschinkel]

@crazyjaco Can you try this one as an candidate for our next release?

https://gist.github.com/mikeschinkel/6db474d6e6ac1b4b2aa6071843a6b264

[crazyjaco]

Hey @mikeschinkel,

Just getting back to this. That gist seemed to work. I can get to the admin login screen for wp-admin. Which means it found my imported database with a custom table prefix. So thats a good start. Something is up for displaying the site's frontend, but I'm not far into debugging that yet. It might be on my side.

I'll check out the slack. How do I access WP-CLI?

[mikeschinkel]

How do I access WP-CLI?

vagrant ssh then wp should work. Not 100% of it works, so we need bug reports for what does not.

You (currently) must have "wordpress/cliapp": "wplib/wp-cli:1.5.1", in your project.json's "stack".

ALSO, I had to update the Gist to support WP CLI. I did not test with it earlier.

[crazyjaco]

looks like i can access wp-cli, but it can't find the right wordpress install. It using the wrong table prefix (wp_ instead of my custom one).

i have my wp-config.php in the root of www.

www

• wp
• content wp-config.php wp-config-boston.local.php

boxuser@boston:/var/www/wp$ wp user list --path='/var/www/wp'
Error: The site you have requested is not installed.
Your table prefix is 'wp_'. Found install with table prefix: BGMP_.
Or, run `wp core install` to create database tables.

[mikeschinkel]

@crazyjaco That looks like a WP CLI configuration error? (I don't use WP-CLI that often.)

[crazyjaco]

I think I see the issue. It seems that $hostname is not yet set in the wp-config.php, when we check it on line 22(ish). $hostname wouldn't be set because we aren't accessing the page load via a url, but via a command line invocation.

[mikeschinkel]

@crazyjaco Did you get the latest Gist I posted in the past hour? I had to fix that $hostname problem.

[crazyjaco]

Yes. My hostname is not wplib.box. And the $_SERVER['HTTP_HOST'] won't be set to the correct value if we're coming in via WP-CLI invocation.

[crazyjaco]

oh wait. I'm seeing i need to create a HOSTNAME file to hardcode it since its different. So it would work without for a normal page request, but not a WP-CLI request.

[crazyjaco]

I created the file. Got a new error.

boxuser@boston:/var/www/wp$ wp user list --path='/var/www/wp'
PHP Warning:  file_get_contents(1): failed to open stream: No such file or directory in phar:///usr/local/bin/wp.bin/php/WP_CLI/Runner.php(1145) : eval()'d code on line 7
Error: The site you have requested is not installed.
Your table prefix is 'wp_'. Found install with table prefix: BGMP_.
Or, run `wp core install` to create database tables.

Directory Structure now: www

• content
• wp wp-config.php wp-config-boston.local.php HOSTNAME

[mikeschinkel]

@crazyjaco I intended HOSTNAME to only be used in rare cases. But yours might be the rare case?

Is your hostname boston.local?

[crazyjaco]

It is. It seems like there is no other way for WP-CLI to know what the hostname is unless its set in that file as things currently stand. (if the file could load, which it doesn't seem to)

I tend to think using a custom hostname and wp-cli at the same time would not be that rare, but I'm not exactly doing out of the box stuff like most users/agencies. So maybe it isn't that common?

[mikeschinkel]

@crazyjaco Damn, there was a typo in the code. Let me update the Gist.

[mikeschinkel]

I updated the Gist. Try it?

[mikeschinkel]

I am on a call so multitasking.

[crazyjaco]

Grabbed your update. Works!!

[crazyjaco]

Doing some testing. The user list command works, at least. I'll let you know what I find.

[crazyjaco]

Couple things: Seeing this when I run WP-CLI commands (which complete successfully)

PHP Notice:  Undefined index: SERVER_NAME in /var/www/wp/wp-includes/pluggable.php on line 333

In addition to that, I might have hit a wall. I can load the admin now and I see that basically my theme and plugins can't be found. My content directory is actually a symlink to the dist folder of my site repo. I can see the symlink within the box, but I'm guess the link doesn't go anywhere because the box doesn't know about my local machine.

Is there some way for me to map my box's 'content' folder to a local folder via the project.json file? I'm guessing no since the skeleton layout wasn't quite working before this.

[mikeschinkel]

@crazyjaco So I updated the Gist yet again, this time to deal with SERVER_NAME, although I would wonder why WP CLI does not handle that? The line in pluggable is inside the wp_mail() command; what WP CLI command did you run that tried to send mail? Of course MailHog should capture that mail.

As for your wall, yeah I think at the moment our architecture does not envision you are going to symlink directories from outside your project root. It is certainly something we can consider adding if the use-case is common enough. Can you explain why you are doing it this way rather than having a repo with all your code and Composer to manage the parts you .gitignore?

BTW, we will soon (~10 days) have an alpha out for our replacement for WPLib Box. It won't require Vagrant and will have lots of other things going for it. We've kinda stopped "polishing" WPLib Box as we have been working on it as its architecture will enough us to do much more than the Vagrant architecture of WPLib Box. While still in alpha and still in beta we are not going to make it publicly available but if you are interested I could include you in our list of testers. DM on our Slack if you are interested.

[crazyjaco]

The command I ran was

wp user list

Shouldn't be triggering any email functionality to my knowledge.

It seems like I got things working by eliminating the symlink and replacing it with a vagrant synced folder that I set in the Vagrantfile.

I haven't seen an easy enough workflow using Composer for daily team development on a full wordpress ecosystem. We're slowly moving this in that direction, but not with a lot of motivation.

Do you have any references for good composer workflows?

[mikeschinkel]

@crazyjaco Interesting. Well that error was definitely in the wp_email() function. Maybe it was phoning home without your knowledge? (Just a conspiracy theory...)

As for good Composer workflows, I have been thinking about blogging about that for a while. You might have given me some motivation to do so. Any chance you want to share with me the issues you have had with it thus far to make sure I address them, here or in Slack?

[crazyjaco]

Can do. Might try to do it in slack.

[crazyjaco]

FYI, tried that updated wp-config (4th revision) with wp-cli and it couldn't find my db table prefix. I reverted to the 3rd revision and tried the wp-cli command again and it worked without errors this time. I don't really understand that, but I'm going to stay at the 3rd revision.