Laravel 5.4 migration: Specified key was too long error solution

Three days ago Laravel 5.4 was released, so I have decided to give it a try. I have made a new Laravel 5.4 project and just when I was about to run the default auth migrations that are shipped with the Laravel almost without any other changes, I got these two red errors:

[Illuminate\Database\QueryException]
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table `users` add unique `users_email_unique`(`email`))

 

[PDOException]
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

What the hell is going on!?!? I have checked the migrations file and everything was okay there unchanged compared to Laravel 5.3. But, according to Laravel Documentation one thing changed:

Laravel 5.4 uses the utf8mb4 character set by default, which includes support for storing “emojis” in the database. If you are upgrading your application from Laravel 5.3, you are not required to switch to this character set.

And, according to their documentation the problem is that I’m running version of MySQL prior to 5.7.7 or MariaDB prior to 10.2.2 (my case). In case you are running versions of MySQL or MariaDB greater than these than most probably that you won’t have this problem at all.

In case you are having this problem – here are the possible solutions:

1. Upgrade MariaDB / MySQL

To update MariaDB on Mac using Brew, first you need to unlink the current one using:

brew unlink mariadb

and then install a dev one using

brew install mariadb --devel

That will install MariaDB version 10.2.3 that works fine. Remember that after installation is done you need to  stop/start the service:

brew services stop mariadb
brew services start mariadb

2. Stick with utf8

In case you don’t want to use the utf8mb4 (that is now setup by default in Laravel 5.4) – instead you want to stick with utf8 that was in use in Laravel 5.3 and all versions before, simply edit /config/database.php  and find these two lines in mysql driver:

'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',

and replace them with with

'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',

That will stop using the utf8mb4 and will change back to utf8. The good thing about this is that you’ll be able to fit 25% more characters into the same columns in database compared with utf8mb4 and that you’ll be able to use existing databases and projects without the need of converting them if you don’t want to. And the downside is that some characters will not be able to be saved to database like this mac command character ⌘ or some emojis. Utf8 can only store Plane Unicode while utf8mb4 can store any unicode character.  Utf8mb4 is also 100% backwards compatible with utf8.

3. Use utf8mb4 without MySQL/MariaDB upgrade

In case you want to use utf8mb4 but you don’t want to or simply can’t upgrade your MySQL/MariaDB there is a simple solution  proposed by Laravel documentation. All you need to do is edit AppServiceProvider located at App\Providers\AppServiceProvider.php and add the following line to the boot() method and load the Schema facade:

use Illuminate\Support\Facades\Schema;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

What that will do is actually change the default maximum field length in the database and actually shorten your maximum string length from 255 to maximum of 191 characters (utf8 uses 3 bytes per character while utf8mb4 uses 4 bytes per character your field can now hold 25% less characters 255 * 75% = 191.25). So if you don’t set the string field by hand in the migration the new default will be 191. You can increase the length if you need it manually by defining it:

$table->string('name', 255);

But this will not be possible on indexed fields since these can’t be longer than 191 characters. So keep this in mind in case you’re planing to use utf8mb4.

In case you want to convert the database from utf8 to utf8mb4 for any existing projects or if you are upgrading from Larvel 5.3 or older to Laravel 5.3 this is the code you need to run for every database, table and column:

Make sure you have the database backups before making these changes!!!!

# For each database:
ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

# For each table:
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

# For each column:
ALTER TABLE table_name CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

# (Don’t just blindly copy-paste this! The exact statement depends on the column type, maximum length, and other properties. The above line is just an example for a `VARCHAR` column.)

Once again: when converting from utf8 to utf8mb4, the maximum length of a column or index key is unchanged in terms of bytes but since utf8mb4 uses 25% more bytes per character your columns can now accept less characters. Therefore, it is smaller in terms of characters, because the maximum length of a character is now four bytes instead of three.

For example, a TINYTEXT column can hold up to 255 bytes, which correlates to 85 three-byte or 63 four-byte characters. Let’s say you have a TINYTEXT column that uses utf8 but must be able to contain more than 63 characters. Given this requirement, you can’t convert this column to utf8mb4 unless you also change the data type to a longer type such as TEXT — because if you’d try to fill it with four-byte characters, you’d only be able to enter 63 characters, but not more.

The same goes for index keys. The InnoDB storage engine has a maximum index length of 767 bytes, so for utf8 or utf8mb4 columns, you can index a maximum of 255 or 191 characters, respectively. If you currently have utf8 columns with indexes longer than 191 characters, you will need to index a smaller number of characters when using utf8mb4.

If you plan on using utf8mb4 make sure to setup your MySQL server accordingly by editing /etc/my.cnf file accordingly:

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

Conclusion

If your application won’t use any special characters or emojis or languages such as Chinese, Japanese, and Korean you’re most probably fine sticking with utf8. But if you can – you should move to utf7mb4 since that will stop you from loosing 4-byte characters when a user ads these in comments or in message or whenever you store these in your database. You should always strive to full unicode support everywhere in your apps and updating your database and code might take some time but it’s definitely worth the time and effort.

Tags: laravel 5 4 migrate, laravel Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes, unique email laravel migration error

CodeIgniter white page on cPanel

After cPanel upgrade from EasyApache3 to EasyApache4 all my CodeIgniter installations just broke on that server, returning just a white page without any error message. I spent more than one hour trying to figure out what the problem is. While testing out I noticed empty files named like these “0bce68a7a37e584ace98f0fd242a237d1662613e” or “296eed9bfb533552b0c3a9c8fdd784067eea216d”   (without any extension) started popping in my project folder. I figured out that these must be session paths so something is wrong with that.

I tried enabling php error logging but it didn’t help since it didn’t log anything since all code is right and it was working before but it just stopped after I started using EasyApache4.

So I went and enabled CodeIgniter logging that proved to be a better idea. To enable it open config.php for editing, locate

$config['log_threshold'] = 0;

And change that value to 4. That will enable internal logging system and logs will be saved in /application/logs folder. What I found out just conf

ERROR - 2016-11-29 22:36:29 --> Severity: Warning --> mkdir(): Invalid path Session_files_driver.php 117
ERROR - 2016-11-29 22:36:29 --> Severity: error --> Exception: Session: Configured save path '' is not a directory, doesn't exist or cannot be created. Session_files_driver.php 119

My session save path at config.php was set to null:

$config['sess_save_path'] = NULL;

Once I got it changed to default (alternatively you can set it up to any other folder you want locally, so you can have full control over your sessions):

$config['sess_save_path'] = sys_get_temp_dir();

everything started working again! Now this is second time I have similar quiet errors with CodeIgniter where it reports absolutely nothing – instead it just gives white screen and this can be really frustrating to debug.

 


	
			
		

Jetpack JSON API failed to activate bug solution

So, this is actually the part 2 of my problems concerning DigitalOcean WordPress 1-click-app and JetPack (about the first issue you can read here). If you read my first post you found out what I had to do in order to activate the Jetpack. All seemed fine and I could see the stats from WordPress installed on DigitalOcean droplet on my WordPress.com account and even some of the active things were working (like Photon or Contact Form).

But, when I wanted to turn on some of the Jetpack modules that I have previously turned off (or that were turned off by default) it didn’t work. For example I wanted to turn off and then turn back on JSON API at General settings tab. When I turned it off it looked like it “worked” (no error messages) but when I wanted to turn it back on I was getting following error message (and the slider won’t go to active position):

JSON API failed to activate. SyntaxError: Unexpected toket < in JSON at position 0

jetpack-json-api-bug

When trying to activate some other Jetpack module I would also get this error:

SyntaxError: JSON Parse error: Unrecognized token ‘<‘” error

I was also unable to disconnect the Jetpack using the WordPress.com account and this was only possible if I would disable Jetpack at plugins and re-enable it again. Then I would have to re-connect it with my WordPress account and it’s a loop but the results were the same. It didn’t work!

I have contacted Jetpack support but their help was similar to Microsoft support (restart the computer and try again), or in Jetpack case: disable all plugins and try reconnecting again. Since Jetpack support was unable to help me after we have exchanged couple of emails I have decided to dig deeper into this on my own. DigitalOcean community also wasn’t helpful since I found just one comment about someone having the same problem as I do but there were no reply or solution.

So I have opened Chrome debugger and have noticed that when I try to activate the JSON API it actually tries to make a POST call to url: /wp-json/jetpack/v4/module/json-api/activate:

wp-json-jetpack-404

and the result is 404 – the standard 404 page! Since there files on that path and WordPress installation doesn’t have wp-json folder at all I figured out that this is mod_rewrite path so I knew in what direction to focus my exploration. I’d like to mention here that this also happened on brand new, zero days blogs, no plugins installed, default theme: basically on out of the box WordPress installations. Also permalinks worked so mod_rewrite was working normally (or it appeared to be working normally), and that made the situation even more confusing.

Out of pure despair I tried re-enabling mod_rewrite and restarting apache:

sudo a2enmod rewrite
sudo service apache2 restart

And it FU*KIN WORKED!!! 

I have tired this on my other 5 or 6 sites hosted on DigitalOcean and it worked on all of them! I hope that some one from Jetpack or some geeks from DigitalOcean will see this post. I’d love to hear more about this issue. How is possible that mod_rewrite is working without being enabled on Apache or if it’s enabled why it doesn’t work for Jetpack plugin? I’m puzzled and I’d like some explanation.

Also I have one more bug that I don’t know how to solve. When I login to these WordPress admins I have this error on every (admin) page I load in my debugger:

Uncaught TypeError: Cannot read property ‘type’ of undefined(…)

This traces back to https://widgets.wp.com/notifications/webpack:/webpack/bootstrap_905f… as you can see in detail on this screenshot:

cannot-read-property-type-of-undefined-bootstra-bug

Update: 05th December 2016
Now Jetpack is works normally on my DigitalOcean droplets, but on some occasions while setting up the Jetpack options I saw this message: Warning! Multibyte support missing!

wp-multibyte

This means that multi-byte support php module was not installed. To get it installed simply install package php-mbstring using apt-get (or yum in case you’re using CentOS/RHEL Linux), restart Apache and you’re good to go!

sudo apt-get install php-mbstring
sudo service apache2 restart

PHP multibyte should now be installed and these messages should no longer appear.

Tags: digitalocean json wordpress

Images won’t center align in WordPress

If you click on the image and hit the Align Center icon inside the editor, it will give to that image a class named “aligncenter” (or left “alignleft” and right to be “alignright” in case you align it left or right) and it will look good in the editor. In some cases once you save the changes and go to check how the image looks on the site you can notice that it’s not properly aligned and instead of being centered your image is right aligned.

This issue occurs on some themes while it works fine on the other (it works nice on the default WordPress theme) and the reason for that is that the theme doesn’t define these aligncenter (or alignleft and alignright) classes in CSS. These are introduced with WordPress 2.5 so some older themes are usually lack this and thus don’t work as expected.

There are some workarounds to solve this issue, but the best one is to just edit default styles.css and add the following css classes in it:

/* =WordPress Core
-------------------------------------------------------------- */
.alignnone {
    margin: 5px 20px 20px 0;
}

.aligncenter,
div.aligncenter {
    display: block;
    margin: 5px auto 5px auto;
}

.alignright {
    float:right;
    margin: 5px 0 20px 20px;
}

.alignleft {
    float: left;
    margin: 5px 20px 20px 0;
}

a img.alignright {
    float: right;
    margin: 5px 0 20px 20px;
}

a img.alignnone {
    margin: 5px 20px 20px 0;
}

a img.alignleft {
    float: left;
    margin: 5px 20px 20px 0;
}

a img.aligncenter {
    display: block;
    margin-left: auto;
    margin-right: auto
}

.wp-caption {
    background: #fff;
    border: 1px solid #f0f0f0;
    max-width: 96%; /* Image does not overflow the content area */
    padding: 5px 3px 10px;
    text-align: center;
}

.wp-caption.alignnone {
    margin: 5px 20px 20px 0;
}

.wp-caption.alignleft {
    margin: 5px 20px 20px 0;
}

.wp-caption.alignright {
    margin: 5px 0 20px 20px;
}

.wp-caption img {
    border: 0 none;
    height: auto;
    margin: 0;
    max-width: 98.5%;
    padding: 0;
    width: auto;
}

.wp-caption p.wp-caption-text {
    font-size: 11px;
    line-height: 17px;
    margin: 0;
    padding: 0 4px 5px;
}

/* Text meant only for screen readers. */
.screen-reader-text {
	clip: rect(1px, 1px, 1px, 1px);
	position: absolute !important;
	height: 1px;
	width: 1px;
	overflow: hidden;
}

.screen-reader-text:focus {
	background-color: #f1f1f1;
	border-radius: 3px;
	box-shadow: 0 0 2px 2px rgba(0, 0, 0, 0.6);
	clip: auto !important;
	color: #21759b;
	display: block;
	font-size: 14px;
	font-size: 0.875rem;
	font-weight: bold;
	height: auto;
	left: 5px;
	line-height: normal;
	padding: 15px 23px 14px;
	text-decoration: none;
	top: 5px;
	width: auto;
	z-index: 100000; /* Above WP toolbar. */
}

 

You can add the code anywhere in the file, but the end of the file is probably your safe bet. Once you save the changes you can reload the site and your images should now be aligned same way as in your editor.

 


JetPack can’t connect to DigitalOcean WordPress 1-click app installation

You made your WordPress blog using DigitalOcean 1-click apps, you have installed Jetpack WordPress plugin but you can’t activate. Instead you’re getting this message:

Error Details: The Jetpack server was unable to communicate with your site [HTTP 500]. Ask your web host if they allow connections from WordPress.com…

jetpack

But the problem is not with the communication between WordPress.com and your DigitalOcean droplet. The problem is with the fact that following php modules were not installed: php7.0-xml and php7.0-xmlrpc.

No we can argue why these were not installed by default: it might be due the fact that this way WordPress XML-RPC will not function and this would automatically reduce the amounts of spam on your blog (more likely) or that that the system would perform (slightly) better without these two modules (less likely) but in order for JetPack to work we need to install these two modules and to restart the apache.

Here are the commands you need to execute in console in order for it to work:

sudo apt-get install php7.0-xml php7.0-xmlrpc
sudo service apache2 restart

 

After you have done this logout out of your WordPress, then login back again and try once again to connect your Jetpack plugin. I hope it will work out for you since it just did it for me on more than 10 different droplets!


How to solve wp-cron.php high CPU usage?

It is known that wp-cron.php file can cause high CPU usage on high traffic WordPress sites. This can also occur on sites hosted on shared or VPS hosting when they receive more traffic than usual at short period of time (traffic spikes).

Typically, every page load calls wp-cron.php to be executed and to run any tasks that are scheduled to be executed (like posting scheduled posts, plugin or theme updates, clearing caches on various caching plugins, sending email notifications etc). This basically asks WordPress: Is it time do do anything now? And then WordPress checks for pending tasks and if there’s nothing to do typically answers with: sorry, but there’s nothing to to at this moment… Try a bit later… and this probably happens in 99% cases. So this wp-cron.php literally nags WordPress all the time with those requests. On low traffic sites, this is perfectly fine but on high traffic sites (or sites with traffic spikes) this can cause higher resource usage, make problems with your hosting (vps/server) and decrease your site performance.

Best way to prevent this wp-cron.php activity is to stop it from running the default way (on every site visit) and then just run it using cron when according your needs.

To stop WordPress from executing wp-cron.php after every page visit, simply add this single line to the end of your wp-config.php file:

define('DISABLE_WP_CRON', 'true');

That’s it! This will lower the CPU/resource usage instantly. But it’s not recommended to never execute wp-cron.php since your WordPress plugins and themes won’t be updated and your scheduled posts won’t be posted etc.

Here is the commands that you can use to run wp-cron.php using a real cron:

/usr/bin/wget -q -O - http://www.yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

There’s no general rule as for the frequency of this cronjob since every site and setup is different. Everything from once per day to every minute is fine but it really depends on your system. If you have tasks that run every 10 or 15 minutes you should probably setup cron to run every 5 minutes. It’s still quite frequent but it won’t happen that you get several cron runs in couple of seconds.

To setup cron at cPanel hosted site login at cPanel, click on Cron Jobs icons and there add a new cronjob like this:

wp-cron-fix

Tags: CPU WP

How to disable xmlrpc.php?

While monitoring my system I have notices increased number of requests to xmlrpc.php. Every single of those requests took 200MB to 205MB of ram and resulted in system instability and in few occasions it caused my 8GB Digital Ocean Droplet to go out of memory and eventually crashed leaving all my sites not working for some 10hours or so.

Recently I’ve read that many hackers now use xmlrpc.php instead of wp-login.php to execute their brute force attacks. And the problem is – since WordPress 3.5 you can’t disable the use of xmlrpc, at least not from the WordPress control panel.

There are many ways to do that and I’ll write some:

1. Deleting xmlrpc.php file
This is really not recommended. Also after WordPress (auto)update the deleted file will be replaced so it’s not really smart to do this, but I just wanted to write this just in case someone doesn’t try to do this.

2. Plugins
There are several plugins that can do this. I found these two to be the most used ones: Disable XML-RPC and  XML-RPC Pinkback. Both plugins are really basic (only couple lines of code) but they should be able to help you out and protect your blog against those attacks.

3. Adding filter to theme functions.php file
This is basically same thing as the plugin above, but you have one plugin less. All you need to do is to edit your theme’s functions.php and add these couple of lines:

function remove_x_pingback($headers) {
    unset($headers['X-Pingback']);
    return $headers;
}
add_filter('wp_headers', 'remove_x_pingback');
add_filter('xmlrpc_enabled', '__return_false');

4. Block access at .htaccess
You can simply add this one line of code to your .htaccess file and block the access to the xmlrpc.php file entirely. User accessing the xmlrpc.php will get the 403 Forbidden error.

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

5. Blocking access in nginx
If you are running nginx instead of Apache you should add this code to your nginx configuration:

server {
    location = /xmlrpc.php {
        deny all;
    }
}

6. Block on entire server
If you have one server or VPS with tens of hundreds of WordPress installations (like me) any of the solutions above will take time to implement. So the best thing to do is to block access to xmlrpc.php file on Apache level, simply by adding this to httpd.conf file:

<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>

Or even better adding this code (that also blocks wp-trackback.php and also prevent’s trackback hacking attempts).

<FilesMatch "^(xmlrpc\.php|wp-trackback\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>

If you don’t use XML-RPC than you can safely disable it using any of the methods above (except the first one, of-course) and protect your blog against xmlrpc hacks.

Tags: apache block xmlrpc php

How to remove “X” from search input field on Chrome and IE

On input fields that are type “search” on HTML5 browsers add some a little blue “X” at top right side that is actually a clear button. It would clear user search input if user clicks on that “X” or if he presses ESC on keyboard. It’s a useful feature, to be sure, but for some stylish search forms it just doesn’t fit and can look quite ugly. While working on one project this became a problem and I was a looking for a way to disable it?

Here’s how it looks like on average field:
input type search with X
Well doesn’t look bad but if you style that box a bit it can look quite ugly…

The first solution was to simply replace type=”search” with type=”text” but that would be just too easy. And why the hell they added search type if I can’t use it! So I was looking for some other solutions. Clearly different browsers have different approaches.

To remove “X” from all search input fields in IE, simply add this to bottom of your css:

input[type=text]::-ms-clear {  display: none; width : 0; height: 0; }
input[type=text]::-ms-reveal {  display: none; width : 0; height: 0; }

To remove “X” from search input field on Chrome Browser (and all it’s mutations), simply add this to bottom of your css:

input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration { display: none; }

The following CSS code should remove that clear button on all search fields on page:

input[type=text]::-ms-clear {  display: none; width : 0; height: 0; }
input[type=text]::-ms-reveal {  display: none; width : 0; height: 0; }
input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration { display: none; }

I have tested this in following browsers IE, Firefox, Chrome and Opera.

Added on May 26th 2014:
I have discovered another Chrome bug/issue that is really annoying in case you have a custom design and you don’t want Chrome to mess with it at all. It happens on all auto-complete forms where Chrome adds yellow background color to the autocomplete fields. Sample picture from WordPress loign page (but it happens on other fields too):

chrome yellow field bug

The solution is easy and all you need to do is to add this code into your CSS and change the color (if needed):

input:-webkit-autofill {
-webkit-box-shadow:0 0 0 50px #ffffff inset;
}

Useful links that can help you solve this problem:

If you have any questions or comments feel free to comment using the comment box below.

Tags: javascript remove internet explorer input clear, ie8 close input, bootstrap add clear field x, html remove x from textbox, IE clear input, ie input bloque cross, ie11 clear field x ms-clear doesnt work, input ms-clear ie11, input remove x, java script data search by cross button, javascript internet explorer textbox with x, little x missing from a field in chrome, remove x in textbox fields, html disable x on input box, how to hide cross icon in textbox IE, chrome clear in input type=search, Cross symbol in input box foe ie browser but not in chrome browser, cross to empty input, css remove ie9 close input, css replace input x, css textbox delete entry, disable ie9 cross button in input, disable the X on IE 11 html input box, edge disable input text cross delete, force chrome style file input in ie, hide clear x in IE html input, how to hide clear from input, remove x on forms

How to add Iframes in WordPress posts or pages

A friend of mine needed some help. He wanted to place iframes inside WordPress posts but WordPress removes those codes automatically. So I searched for solutions and found this pretty simple one. All you need to do is to add these 4-5 lines of code to functions.php located in your theme’s folder.

function add_iframe($initArray) {
$initArray['extended_valid_elements'] = "iframe[id|class|title|style|align|frameborder|height|longdesc|marginheight|marginwidth|name|scrolling|src|width]";
return $initArray;
}
add_filter('tiny_mce_before_init', 'add_iframe');

You can get there by going Appearance -> Editor -> Theme Functions (functions.php). If there’s no functions.php you’ll have to create one (to do so you must login to FTP or to your cPanel and create a functions.php file by hand in theme’s folder and then place this code in it. Don’t forget to open and close php segment.

Now WordPress will not remove iframes from your posts or pages!
Hope it helps!

Tags: wordpress iframe, iframe wordpress, iframe in wordpress, iframe wordpress page, iframes in wordpress, wordpress iframe in page, adding a iframe to wordpress home page

WordPress 3.5 custom media upload path missing

After WordPress 3.5 was released many of useful options were removed or simply disabled because of some reason. One of those options is possibility to define custom path where you want your pictures (and other media files) to be uploaded. This is really important in case – you want to use CDN or you want to use some other web server to serve that static content (both are simply a must for medium and big sites).

So if you go to Settings -> Media in your WordPress (versions after 3.5) you will see something like this:
wordpres uploading files no custom paths

And it should look like this (versions prior 3.5):
wordpress uploading files with custom paths

In order to enable custom media upload paths go to phpMyAdmin and open Database of your WordPress 3.5 installation, then locate table wp_options (could be different depending on your prefix) and then those two option_name inputs:
phpmyadmin wp_options
And change them according to your needs.

Same domain just different folder Example
upload_path to images
upload_url_path to http://www.yoursite.com/images

Subdomain example
upload_path to images
upload_url_path to http://images.yoursite.com
– then go to cPanel and setup that subdomain like this
cPanel subdomains
cpanel making subdomain

After setting those two values in phpMyAdmin those two forms will appear in WordPress so you can change it’s values if needed. If this helped you out please post some comments. Also if you need any help or experience any problems – feel free to leave a comment.

Tags: spintires media path missing