Website Developers eCommerce eMarketing
For a free consultation 787 -557-3109
Web Developers Knowledge Center
  PR Market Web Developers, Inc. "We make it happen, always and on time"

WordPress on PRMWD Cloud Hosting

Jan 26


Frequently Asked Questions

1. PRMWD Hosting for  WordPress Install?    

It's simple. The installation may take up to 15 minutes for installation and DNS propagation.


2. Does this installer work on previously created sites?  

No, not at this time. The installer is only for new site creation at this time. We are evaluating what would be required for implementing this on existing sites, but at this point we do not have a method that would not potentially overwrite or jeopardize content that already exists on the customers site. Since we do not want to be held responsible for overwriting content, we have chosen to limit this to new site adds only at this time.    

If desired, customers can delete an existing site, recreate it, and use the CMS installer, but note that all database, email and other site content will be erased and will need to be set up again.


3. Can I select the technology that this installs on?   

The CMS is setup to install only on PHP 5.3 and deploys a MySQL 5.1 database. You cannot select an alternate technology for this installation. You are able to perform manual installations on other technologies, but this 1-click installer defaults only to PHP 5.3.


4. Does this installation automatically update the version of WordPress automatically?    

No, PRMWD Cloud Sites does not automatically update your version of WordPress as the product is not a CMS management utility. However, version updates are very simple in the WordPress management dashboard. Click updates and you will see if a new version is available. If so, click install and it is performed for you. You are strongly urged to stay up to date on the version of WordPress as older versions are easily compromised, so please keep your version up to date for the most secure site.


5. Can I select the sub-directory or sub-domain where this is installed?

No, not at this time, but we are considering enabling that in the future.


6. Test link support - I just installed Wordpress and the Test Link displays the new install unformatted, did the installer fail?

No, the installer most likely completed and installed Wordpress just fine. The reason the test link is not displaying the site correctly is due to the fact that the our installer uses the actual URL for the Wordpress installation. Since Wordpress stores the site URL into the database you can only visit the site from the actual site URL. There are two ways to overcome this for testing purposes.

  • If you have already pointed your DNS to PRMWD Cloud Sites you can simply visit the actual site URL and the site should display and function correctly.
  • The recommended method for dealing with this issue is to edit your local computer's hosts file so that your local computer will display the site using the Cloud Sites IP address. This process will be different depending on whether your local computer is a Windows, Linux, or Mac computer. See: How do I modify my hosts file?
  • Lastly, if you haven't already setup your DNS to point to PRMWD Cloud Sites and you are not able to modify your local hosts file, you can modify the Wordpress installation so that the Test Link is the URL used by Wordpress. See:Changing The Site URL (Wordpress Codex)


7. Does this installer work for all web browsers?   

This has been tested and is functional for Chrome, Firefox and Safari.  We are now testing IE and expect to have clarity on this in the very near future.  


8. How do I perform a manual installation of WordPress on an existing site? 

You can reference the content listed here for manually installing WordPress on PRMWD Cloud Sites: Install And use WordPress On Cloud Sites

Let us know
comments (0)
Jan 26


On the Settings->General screen in a single site installation of WordPress, there are two fields named 

"WordPress address (URL)" and "Site address (URL)". 

These are also known as the "Home" and "Site URL" settings. 

They are important settings, since they control where WordPress thinks your site is located. 

They control the display of the URL in the admin section of your page as well as 

the front end, and are used throughout the WordPress code.

  • The "Home" setting is the address you want people to type in their browser to reach your WordPress blog.
  • The "Site URL" setting is the address where your WordPress core files reside.

Note: Both settings should include the http:// part and should not have a slash "/" at the end.

Every once in a while, somebody finds a need to manually change (or fix) these settings. Usually this happens when they change one or both and discover that their site no longer works properly. This can leave the user with no easily discoverable way to correct the problem. This article tells you how to change these settings directly.

Additional information is presented here for the case where you are moving WordPress from one site to another, as this will also require changing the site URL. You should not attempt to use this additional information if you're only attempting to correct a "broken" site.

Alert! These directions are for single installs of WordPress only. If you are using WordPress MultiSite, you will need to manually edit your database.



Changing the Site URL

There are four easy methods to change the Site URL manually. Any of these methods will work and perform much the same function.

Edit wp-config.php

It is possible to set the site URL manually in the wp-config.php file.

Add these two lines to your wp-config.php, where "" is the correct location of your site.


This is not necessarily the best fix, it's just hardcoding the values into the site itself. You won't be able to edit them on the General settings page anymore when using this method.

Edit functions.php

If you have access to the site via FTP, then this method will help you quickly get a site back up and running, if you changed those values incorrectly.

1. FTP to the site, and get a copy of the active theme's functions.php file. You're going to edit it in a simple text editor (like notepad) and upload it back to the site.

2. Add these two lines to the file, immediately after the initial "<?php" line.


Use your own URL instead of, obviously.

3. Upload the file back to your site, in the same location. FileZilla offers a handy "edit file" function to do all of the above rapidly; if you can use that, do so.

4. Load the login or admin page a couple of times. The site should come back up.

5. Repeat the above steps, but remove those lines. IMPORTANT: Do NOT leave those lines in there. Remove them immediately after the site is up and running again.

If there is no functions.php file in the theme:

Create a new text file called "functions.php".

Edit it with notepad, and add this text to it, using your own URL instead of


Upload that to your theme directory, then proceed as stated above. Remove the file afterwards.


Here are some additional details that step you through transfering a LAN-based wordpress site into an externally accessible site as well enabling editing the wordpress site from inside the LAN.

Two important keys are router/firewall modifications and the "wait 10+ minutes" after making the changes at the end.

-using ssh to log into your server (nano is a server preinstalled text editor)
-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-add lines just after <?php


-refresh your web browser using your external site url

-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-remove those lines you just added (or comment them out)
-access your router (these steps are for pfSense, other routers should have similar settings to look for/watch out for)
-add to firewall/nat table a line like this


-add to firewall/rules table a line like this


-uncheck the box at System/advanced/network address translation/Disable NAT Reflection

       "Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports."

Then go do something for ten minutes and when you get back see if the external url from a LAN browser brings the page up correctly.

Relocate method

WordPress supports an automatic relocation method intended to be a quick assist to getting a site working when relocating a site from one server to another.


1. Edit the wp-config.php file.

2. After the "define" statements (just before the comment line that says "That's all, stop editing!"),

 insert a new line, and type: define('RELOCATE',true);

3. Save your wp-config.php file.

4. Open a web browser and manually point it to wp-login.php on the new server. 

For example, if your new 

site is at,

 then type into your browser's address bar.

5. Login as per normal.

6. Look in your web browser's address bar to verify that you have, indeed, logged in to the correct server. 

If this is the case, then in the Admin back-end, navigate to Settings > General and 

verify that both the address settings are correct. Remember to Save Changes.

7. Once this has been fixed, edit wp-config.php and either completely remove t

he line that you added (delete the whole line), comment it out (with //) or 

change the true value to false if you think it's likely you will be relocating again.

Note: When the RELOCATE flag is set to true, the Site URL will be automatically updated 

to whatever path you are using to access the login screen. 

This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.

Changing the URL directly in the database

If you know how to access phpMyAdmin on your host, then you can edit these values directly to get you up and running again.

  1. Backup your database and save the copy off-site.
  2. Login to phpMyAdmin.
  3. Click the link to your Databases.
  4. A list of your databases will appear. Choose the one that is your WordPress database.
  5. All the tables in your database will appear on the screen.
  6. From the list, look for wp_optionsNote: The table prefix of wp_ may be different if you changed it when installing.
  7. Click on the small icon indicated as Browse.
  8. A screen will open with a list of the fields within the wp_options table.
  9. Under the field option_name, scroll down and look for siteurl.
  10. Click the Edit Field icon which usually is found at the far left at the beginning of the row.
  11. The Edit Field window will appear.
  12. In the input box for option_value, carefully change the URL information to the new address.
  13. Verify this is correct and click Go to save the information.
  14. You should be returned to your wp_options table.
  15. Look for the home field in the table and click Edit FieldNote There are several pages of tables inside wp_options. Look for the> symbol to page through them.
  16. In the input box for option_value, carefully change the URL information to the new address.
  17. Verify this is correct and click Go to save the information.

Moving Sites

When moving sites from one location to another, it is sometimes necessary to manually modify data in the database to make the new site URL information to be recognized properly. Many tools exist to assist with this, and those should generally be used instead of manual modifications.

This is presented here as information only. This data may not be complete or accurate.

You should read the Moving WordPress article first, if attempting to move WordPress from one system to another.

Altering Table Prefixes

Like many WordPress administrators, you may be running several WordPress installations off of one database using various wp-config.php hacks. Many of these hacks involve dynamically setting table prefixes, and if you do end up altering your table prefix, you must update several entries within the prefix_usermeta table as well.

As in the above section, remember that SQL changes are permanent and so you should back up your database first:

If you are changing table prefixes for a site, then remember to alter the table prefix in the usermeta tables as well. This will allow the new site to properly recognize user permissions from the old site.

UPDATE `newprefix_usermeta` SET `meta_key` = REPLACE( `meta_key` , 'oldprefix_', 'newprefix_' );

Changing Template Files

In your WordPress Theme, open each template file and search for any manually entered references to your old domain name and replace it with the new one. Look for specific hand coded links you may have entered on the various template files such as thesidebar.php and footer.php.

WordPress uses a template tag called bloginfo() to automatically generate your site address from information entered in yourAdministration > Settings > General panel. The tag in your template files will not have to be modified.

Changing the Config file

You will need to update your WordPress configuration file if your database has moved or changed in certain ways.

  1. You will only need to modify the config file if:
    1. your database has moved to another server and is not running on your localhost
    2. you have renamed your database
    3. you have changed the database user name
  2. "'Make a backup copy of your wp-config.php file.'"
  3. Open the wp-config.php file in a text editor.
  4. Review its contents. In particular, you are looking for the database host entry.
  5. Save the file.

At this point, your WordPress blog should be working.

Verify the Profile

  1. In your Administration Panels go to Settings > General . Here you will verify that the changes you made in Changing the URLabove, are correct.
  2. Verify that the reference in your WordPress Address (URL) contains the new address.
  3. Verify that the reference in your Site Address (URL) contains the new address.
  4. If you have made changes, click Save Changes.

Changing the .htaccess file

After changing the information in your Administration > Settings > General panel, you will need to update your .htaccess file if you are using Permalinks or any rewrites or redirects.

  1. Make a backup copy of your .htaccess file. This is not a recommendation but a requirement.
  2. Open the .htaccess file in a text editor.
  3. Review its contents, looking for any custom rewrites or redirects you entered. Copy these to another text file for safe keeping.
  4. Close the file.
  5. Follow the instructions on the Permalinks SubPanel for updating your Permalinks to the .htaccess file.
  6. Open the new .htaccess file and check to see if your custom rewrites and redirects are still there. If not, copy them from the saved file and paste them into the new .htaccess file.
  7. Make any changes necessary in those custom rewrites and redirects to reflect the new site address.
  8. Save the file.
  9. Test those redirects to ensure they are working.

If you make a mistake, you can Restoring Your Database From Backup from your backup and try this again. So make sure it is right the first time.

Additional items of note

There are other things you may wish to change in order to correct URLs when moving sites.

  1. Images link: image links are stored in "post_content" in the wp_posts table. You can use the similar code above to update image links.
  2. wp_options: Besides the "siteurl" and "home" items mentioned above, there are other option_value which also need revision, such as "upload path", and some plugin items (depends on what you've installed, such as widgets, stats, DMSGuestbook, sitemap, etc.)
  3. To fix widgets that contain outdated URL's, you may edit them in Dashboard / Appearance / Widgets.
  4. Do a FULL database search for any items left. MAKE SURE you know what you are changing. and go through each item for possible improper replacement.
  5. If you a running a network / have multiple sites, you will need to replace instances of the URL in the database. They are stored in many tables, including each one of the sites (blogs). Be careful in what you replace and be sure you know the meaning of the field before changing it. See the Important GUID note below for an example of what not to change.
  6. Note, if you find your old url in the database options table under 'dashboard_incoming_links', you can ignore or delete that option. It's unused since WP 3.8.

How To: Move Your WordPress Blog to a New Domain - Using the Export/Import feature to move a blog to a new domain

Important GUID Note

When doing the above and changing the URLs directly in the database, you will come across instances of the URL being located in the "guid" column in the wp_posts tables.

It is critical that you do NOT change the contents of this field.

The term "GUID" stands for "Globally Unique Identifier". It is a field that is intended to hold an identifier for the post which a) is unique across the whole of space and time and b) never, ever changes. The GUID field is primarily used to create the WordPress feeds.

When a feed-reader is reading feeds, it uses the contents of the GUID field to know whether or not it has displayed a particular item before. It does this in one of various ways, but the most common method is simply to store a list of GUID's that it has already displayed and "marked as read" or similar.

Thus, changing the GUID will mean that many feedreaders will suddenly display your content in the user's reader again as if it was new content, possibly annoying your users.

In order for the GUID field to be "globally" unique, it is an accepted convention that the URL or some representation of the URL is used. Thus, if you own, then you're the only one using and thus it's unique to you and your site. This is why WordPress uses the permalink, or some form thereof, for the GUID.

However, the second part of that is that the GUID must never change. Even if you shift domains around, the post is still the same post, even in a new location. Feed readers being shifted to your new feeds when you change URLs should still know that they've read some of your posts before, and thus the GUID must remain unchanged.

Never, ever, change the contents of the GUID column, under any circumstances.

One exception is attachment media: Attachment media locations are stored as a URL in the GUID. If the default uploads folder needs to be changed to a different location, then the media URL will need to be changed in the post_content and guid columns of the posts table. For example, if the default uploads folder is changing from wp-content/uploads to images:

UPDATE wp_posts SET post_content = REPLACE(post_content,'','');
UPDATE wp_posts SET guid = REPLACE(guid,'','');

Multi-site notes

See Moving WordPress Multisite


wp-cli is a super useful shell tool.

wp search-replace '' ''

Or, if you only want to change the option, you can do:

wp option update home ''
wp option update siteurl ''

Let us know
comments (0)
Jan 26


How do I modify my hosts file?

Modifying your hosts file will allow you to override the DNS for a domain, on that particular machine. This can be used to test your site without the test link, prior to going live with SSL, verify an alias site works prior to DNS changes, or for other DNS related reasons. This causes your local machine only to look directly at the IP specified.

Your hosts file will need to have two entries added that will contain the IP address you want the site to resolve to and the address. Adding the below two lines for example will point and to our current PHP5-ITK ("Refreshed" PHP5) cluster:

Below is how to locate and edit the hosts file on several OS platforms. Once the proper domain information is added you will save the file and your system will begin resolving to the specified IP. Once testing is finished these entries should be removed.


  • Windows Vista and Windows 7
  • Windows NT/2000/XP
  • Linux
  • Mac OSX 10.0 - 10.1.5
  • Mac OSX 10.6 - 10.8


Windows Vista and Windows 7

Vista and Windows 7 use User Account Control (UAC) so Notepad must be run as Administrator.

1. Click Start -> All Programs -> Accessories

2. Right click Notepad and select Run as administrator

3. Click Continue on the "Windows needs your permission" UAC window.

4. When Notepad opens Click File -> Open

5. In the filename field type C:WindowsSystem32Driversetchosts

6. Click Open


Windows NT/2000/XP

1. Click Start -> All Programs -> Accessories -> Notepad

2. Click File -> Open

3. In the filename field type C:WindowsSystem32Driversetchosts

4. Click Open



1. Open a terminal window

2. Type sudo nano /etc/hosts (you can substitute any text editor)

3. Enter your password


Mac OS X 10.0 - 10.1.5

1. Open /Applications/Utilities/NetInfo Manager.

2. To allow editing the NetInfo database, click the padlock in the lower left corner of the window.

3. Enter your Admin password and click OK

4. In the second column of the browser view, select the node named "machines." You will see entries for -DHCP-, broadcasthost, and localhost in the third column.

5. The quickest way to create a new entry is to duplicate an existing one. So select the "localhost" item in the third column.

6. Choose Duplicate from the Edit menu. A confirmation alert appears.

7. Click Duplicate. A new entry called "localhost copy" appears, and its properties are shown below the browser view.

8. Double-click the value of the ip_address property and enter the IP address of the other computer.

9. Double-click the value of the name property and enter the hostname you want for the other computer.

10. Click the serves property and choose Delete from the Edit menu.

11. Choose Save from the File menu. A confirmation alert appears.

12. Click Update this copy.

13. Repeat steps 6 through 12 for each additional host entry you wish to add.

14. Choose Quit from the NetInfo Manager menu. You do not need to restart the computer. 


Mac OS X 10.6 - 10.1.8

1. Open Applications > Utilities > Terminal.

2. Open the hosts file by typing the following in the Terminal window:

sudo nano /private/etc/hosts

Type your user password when prompted

3. Edit the Host File,The hosts file contains some comments (lines starting with the # symbol), as well as some default hostname mappings (e.g. ” local host). Append your new mappings underneath the default ones.

4. Save the Host File, When done editing the hosts file, press Control+x to save the file.

5. Make your changes take effect by flushing the DNS cache with the following command:

$ dscacheutil -flushcache

6. New mappings should now take effect.

Let us know
comments (0)