With a dynamic (non-wordpress) website at root, how to install WordPress in a subdirectory on a droplet having Ubuntu 18.04 and LAMP stack?

August 17, 2018 800 views
WordPress LAMP Stack PHP MySQL Apache Ubuntu Ubuntu 18.04

Hello DO community,

I’ve come across a strange situation for installing a WordPress on a droplet having LAMP stack. I looked around on the Q/As around but no proper relevant ones, as well as the ones which were relevant didn’t work. I’ll try to be as precise as possible below

Situation: The Droplet is on Ubuntu 18.04, with LAMP stack installed. Due to some reasons, It is running php 7.1 from the external library. Lets assume the website is xyz.com. The website is dynamic (non-WordPress) and already utilizes a particular MySQL database.

Aim: To have a blog section on it, with WordPress installed in it, in a subdirectory called blog. Therefore its URL will be xyz.com/blog

Steps Taken: Facing the same problem, tried it twice using two ways,

first - uploading the WordPress files via FTP to the required directory and making the databases via adminer (alternative to phpmyadmin)

Second - Following the steps provided in This Tutorial

In both the above cases, I have named my database for wordpress ‘blog’ and for the second procedure, I have replaced the path to /var/www/xyz.com/html/blog (I am using virtual host for root site)

Problem Being Faced:
After all of this, when I run xyz.com/blog , the install script begins, prompts to select language. On the next screen (step-2), prompts to take username, password, blog name, etc. once I fill all the details and hit submit, it returns to the same screen (step-2 itself) prompting: Please provide a valid username.

Upon cross checking the database till this step, there’s no table created.
Upon checking the error log at /var/log/apache2 it shows the following error

WordPress database error Table 'blog.wp_options' doesn't exist for query INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('nonce_salt', 'dfgdfgdfdfg1f}mH#cdfgfdgdfgdfgdfgdfgddfgdfgwpxS(EYk3A(6cup*P7jy', 'no') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) made by wp_can_install_language_pack, WP_Upgrader->fs_connect, Automatic_Upgrader_Skin->request_filesystem_credentials, WP_Upgrader_Skin->request_filesystem_credentials, request_filesystem_credentials, wp_nonce_field, wp_create_nonce, wp_hash, wp_salt, update_site_option, update_network_option, add_network_option, add_option

This entire situation is strange and new to me. Kindly help to tackle the problem ASAP, as I’m really struck in the situation.

Thanks in advance

2 Answers

An easy fix would be to spin'off a droplet for a couple minutes, install WP on it and move it over to the old droplet by importing the already created DB and files. I’d like to help solve the issue itself but i’m rather unfamiliar with databases plus it’s probably faster my way. :D

Sounds like there might be an issue with the database user you provided in that second step. Are you able to confirm that the database user you provided there exists in your MySQL system, and that it has full access to your “Blog” database (i.e. can does it have permissions to create tables and write to them)?

  • I’m doubting the same. However, the same user, user pass and hostname work just fine for the database that’s effective on the website on root. Since I’m less used to for command line MySQL, I’ve tried logging in from adminer using the same username and password, and was able to make changes to the database ‘Blog’. How should I cross check? Or any other option that I could consider

Have another answer? Share your knowledge.