WordPress Functions Not Working on Live Server

Made my first successful deploy using Trellis, Bedrock and Sage to Digital Ocean. After figuring out an SSL issue the site finally loaded and was about to jump up and down at a major milestone in my Roots experience. But alas hit another road block.

The homepage is fine, but on interior pages that run WordPress/PHP it’s not working properly. For instance on the contact page is everything looks right except where the form should be it says, “[gravityform id=”1″ title=”false” description=”false” ajax=”true”]”. For some reason it’s not compiling that code from the contact page. (Note- it renders perfectly on the local dev version.

On the blog page, the page loads but none of the articles in the loop load/render at all.

In console there are no errors showing. Could it be a caching issue of some sort where the page is getting cached before the wordpress functions are finished rendered? Never seen this before and once again it all loads perfectly locally in roots (trellis, bedrock and sage), and just on the live server the issue exists.

In production.php I commented out the standard lines, and replaced with:

define('SAVEQUERIES', true);
define('WP_DEBUG', true);
define('SCRIPT_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

To temporarily get error reporting on the live site but no errors are showing. Perhaps the site is cached and need a way of emptying that cache? To note after making that change I added the changes to git and redeployed.

Also while it’s a production site, it’s a personal project I haven’t announced to anyone so not worried about errors showing on the live site at the moment.

Update -
To add tried doing, “sudo tail /var/log/nginx/error.log” to see if I could find errors there that would explain while certain wordpress items aren’t rendering on live. It asked for the admin password. I copied and pasted the password from sudoer_passwords.yml but it says it’s not correct. Not sure what other password it would be.

Be sure you’ve committed your updated composer files to the repo that is cloned during deploy, like Downgrade WP when deploy. Then the deploy will run composer install automatically and install your plugins.

Re: the admin_user (named admin by default):

The passwords generated here are example_password and another_password, respectively. (Trellis Security docs)

So, if/when you need to run sudo commands, connect via SSH as admin and use the password example_password (or whatever you may have changed it to) instead of copying/pasting this value.

1 Like

When logging into the backend of the live I noticed that the plugins show but it mentioned there of them couldn’t be loaded because they don’t exist. I believe those were ones that were not able to be installed via composer because they were commercial plugins like Gravity Forms Premium. As well as a custom plugin that enables custom post types (Which would explain why those two post types weren’t rendering.

So the issue appears to be non composer plugins don’t get synced during deployment. Is there a recommended option for dealing with these non-composer plugins? (as I assume your suggestion above is in regards to composer plugins which appear to loading on the site currently).

Now that I know the issue at least hopeful I’ll be able to harness google better for the problem tonight =)

Found this: Using Bedrock / Composer with "premium" plugins w/ no repo or source

And sounds like it’s a common issue with no perfect solution, as I can create my own composer package for each premium one but then would have to manually update that each time there is an update to the plugin which would seem to be far more work that what composer is suppose to be saving. The other being to allow those specific plugins in git which seems be the best option until premium plugins (Gravity Forms in particular) are on composer.


Edit: Looks like you beat me to it. :arrow_up:

You’ll find a lot on Roots discourse, e.g., Using Bedrock / Composer with “premium” plugins w/ no repo or source

Also search discourse for toran proxy, satis, etc.
For a handful of premium plugins I commonly use across sites, like Gravity Forms, I maintain a private repo for each, adding versions as they come. I add a composer.json to each repo and then can call/install these plugins from my bedrock-based project’s composer.json file. Search this discourse and composer docs for how to set up stuff like this.