I normally use a Blueprint when spinning up new sites but tonight I wanted to start a site with a completely fresh install, DB etc. So I created a site using the Local “Create a new site” button and selected the “Preferred” environment.
On inspecting the wp-config.php file, I found the Unique Keys & SALTS dropped into the bottom of the file, right before the /* That’s all, stop editing! Happy publishing. */ comment. Can’t say I’ve ever seen that before…
What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc
Thanks for looking into this Nick, this app is becoming increasingly frustrating for me…
I stopped all of the sites and shut down last night. Fired Local up again just now and created a dummy site to test => wp=config.php is still messed up.
Hey Nick, just FYI I ended up removing the Local app from my machine again and downloading a fresh local-7.1.0-mac.dmg file.
I deleted the previous app from ~/Applications
I renamed my websites folder name and dragged it to a safe location so I can access the files and DB’s later
I reset my system’s hosts file
I proceeded with the install, went default with EVERYTHING in Settings. Spin up a new test site new-install.local and the wp-config.php file is messed up; same as with the previous installation…
Rewinding here a little bit. To clarify is this giving you any errors or causing any issues in your workflow and development? Or is it just something you noticed? We just wanted to see if you were getting any actual errors or blocks due to this that we could try and replicate.
Hi Nick, no discernible issues that I’m aware of. It doesn’t really matter ‘exactly’ where those declarations are amongst the other user defined options, just makes for a messy file. I’ve since put them back where they belong and created a blank WP blueprint from the site. This obviously works, and I’ll use this instead, for now, but it’s something else I now have to ‘maintain’.
I spun up a new WP installation on a Live Staging server yesterday, just to make sure it wasn’t a WP Core issue, and no problem.
There’s something not quite right in the Local WP install process…
On a related note; how do I stop Local from writing to wp-config.php and setting the development environment? I prefer to set my own dev options.
I already add a block of code to wp-config.php on all of my dev sites which includes this, along with setting the WP_DEBUG and WP_DEVELOPMENT_MODE constants. Having LocalWP add it “twice” just adds another task to my workflow. Unfortunately LocalWP adds this even when using a Blueprint, so I have no option but to go in manually and remove it!
From what I can understand, LocalWP now scans a site’s php.ini file and looks for the WP_ENVIRONMENT_TYPE constant. If it’s not found, LocalWP uses the auto-prepend-file feature to prepend a PHP file that sets the constant in wp-config.php automatically.
Perhaps there’s a very good reason the dev team does this, but I’m not sure why… The practical implementation of this “feature” is above my pay grade unfortunately. If I get some spare time I may look at adding a php.ini file to my Blueprints and see if that solves my use-case.
I’d just prefer not to have to deal with it or have the option in the UI to toggle it on or off.
Hi @krackedkreative - just wanted to pop in and provide more details on the implementation here.
Local used to use a bootstrap file to prepend the environment type. This was before WP_ENVIRONMENT_TYPE was more widely used, and it is not how the app works anymore.
Now, when a site starts or is created, Local checks if a) the wp-config.php exists and b) if it has a WP_ENVIRONMENT_TYPE already set. If so, Local leaves it alone. If not, Local sets it to local and moves on.
On this comment:
Local will respect the value of WP_ENVIRONMENT_TYPE in a blueprint; using production Local, I just set mine to production on a site, saved it as a Blueprint, created a new site from that Blueprint, and confirmed the newly created site had production still set in the wp-config.php.
I understand wanting to have a better place in the UI to manage the setting - I’ll count that as a vote towards the feature request you linked!
