Configure the database host if you do not know which one is

At the time of install WordPress one of the basic elements to be able to connect to the database in addition to the user and MySQL key is the server name, the one known as hostname a data that is normally provided by your hosting provider, but what if you do not find it?

As indicated by the same installation screen of WordPress, in 99% of the occasions the server name is localhost but you will know that it is precisely 1% that usually gives war, especially when your hosting provider does not make things easier for you.

But if localhost does not work for you and you're not in any of the previous providers you can always use a trick of the configuration file wp-config.php that will get you out of the mess on more than one occasion.

What the new line does is try to resolve the host of the database without having to enter it manually. You save the changes and most of the time you will recover the name of your server and everything will work correctly.

Custom permanent links in WordPress installed locally • WordPress Help

 rewrite module

A local installation of WordPress is very useful . There are many occasions when you can take advantage of this despite the fact that this type of facility has its drawbacks.

Either to give courses where you do not have Internet guaranteed, or to test with versions in development, a local installation it is a good resource . Personally I do not love them and I always prefer to do online tests, but it's true that they take you out of more than one hurry and that's why I always have a local installation that I try to have updated.

One of the drawbacks of local WordPress installations, through the systems of type WAMP, XAMPP or MAMP, is that if you change the permanent links of the default option to others as you usually have an ugly error . C'mon, permanent links do not work except the default ones of type http: // localhost: 8888 /? P = 06 .

This is because it is possible that the module rewrite of Apache is not active that is, the one already known by all mod_rewrite .

To make sure that permanent permanent links work, you just have to go to the main window of your WAMP , XAMPP or MAMP and, in the tab corresponding to Apache check that the rewrite_module is selected and if not it marks it to be activated and you restart the local server so that the changes are applied

 rewrite apache mamp

Now should already work . If not, you will have to add the corresponding rewrite rules to the file . Htaccess as indicated in the permanent links settings window, nothing more.

Only as a reminder I leave you a few links on how to install WordPress locally:

  1. Install WordPress on Windows
  2. Install WordPress on Mac
  3. Install WordPress on Ubuntu

NOTICE : this publication is from two years ago or more. If it's a code or a plugin it might not work in the latest versions of WordPress, and if it's a news story it might be obsolete. Then do not say we have not warned you.

Loading …

That may also help you:

Varnish and WordPress

Like the other day I commented something about Varnish and a new plugin and some of you already asked in the comments, I think It was already time for to explain what is Varnish a really powerful cache system, fantastic for WordPress installations with a lot of traffic, and that as you can imagine use here in WordPress Help .

Let's go then …

What is Varnish?

Varnish Cache is a web accelerator or an HTTP cache system of reverse proxy . It is installed on any server that serves (OK, it is redundant) HTTP and is configured to cache its contents . According to some studies accelerates the service by 70% .

Cachear a web, if someone does not know it yet, is to store a copy of it to be what they see future visitors. In the case of Varnish and WordPress, what you get is to serve cached (stored) pages of your WordPress so you do not have to make calls to the database every time someone visits your website. This reduces server load because it simply serves a single copy of the pages to all visitors without having to search for the same images and services for each content and each visitor.

Additionally, Varnish caches pages in memory virtual so that your site loads much faster, which incidentally improves your SEO, because Google has estimated that for every half second of additional load time of a website it receives an average of 20% fewer visitors ( source ). In this way, reducing with Varnish in an important way the page load time can increase your visits and improve your search engine ranking something always to be taken into account.

The people of Varnish have published a very simple video, while explanatory that surely illustrates what it does …

Installing Varnish

Varnish is a free software so you have no excuses to install it right now. It runs on Linux preferably on FreeBSD, but it can work equally on other platforms. Once you install it you can customize it to define how many incoming requests it will manage using the Varnish Configuration Language ( Varnish Configuration Language or VCL).

Varnish is designed so that be flexible so that you can install it thinking of a specific place in mind, and adapt it in a personalized way to it.

Ideally start with a basic configuration of Varnish for later go testing small changes and see how they affect the performance of the particular site. There are several subroutines that tell Varnish how to respond to incoming and outgoing requests, errors, etc.

So let's start with a basic configuration, and then take a look at the basic functions of the VCL and then you tune it to your liking.

Step by step

Starting Varnish is quite simple. Starting from a base of, say, Apache in a system Debian (most Linux servers), although it also works in the rest, we would start with this command:

First you have to configure Apache so that "Listen" to port 8080 of localhost. Varnish will then be able to listen to port 80 (where the visits come from). In file /etc/apache2/ports.conf edit these settings:

To start Varnish (by default it does not ), edit the following in the file / etc / default / varnish

Replace IP_EXTERNAL_DRIVE with the IP of your external IP address. It can also be an internal address if your server is after a load balancer or something like NGINX . This setting controls which IP address and port you want Varnish to listen to and watch.

Once the above is done, edit the file /etc/varnish/default.vcl which should already exist, with much of its Content commented (not active). We will start by changing the backend default .

Now Varnish already knows that Apache is listening to port 8080 and the localhost interface, so we can start using functions. Most of the work will be done with vcl_recv and vcl_fetch, and if you do not call an action in this subroutine and Varnish reaches the end, it will execute the code it finds in the file default.vcl.

Note: no caches ever wp_admin wp_login or similar routes.

This is how it works – the 4 basic subroutines of your Varnish configuration that you need to manage requests will be:

This call is made at the beginning of a request, and tells Varnish what to do with that particular request: if it has to serve it, how to serve it, and what backup to use.

Varnish receives a request from your browser, and then vcl_recv decides to make a 3 costs with it: vcl_hash, vcl_pass, and vcl_pipe ] (Now I explain). You can change the request if you want, alter the cookies or remove the header of the request.

A vcl_fetch is called after a document has been successfully retrieved. You use this to alter the response headers, launch the ESI processing, or to try to alternate between backup servers if the request fails.

The requested object, req is still available, and there is also a backup response, beresp which contains the HTTP headers of the backup.

You can call hash_data of the data you want to add to the hash. This subroutine can end with a call to return () with one of these keywords: hash or proceed .

You call this before the object cacheado is delivered to the client. This may end with deliver, error code, or restart. Deliver delivers the object to the client, error returns the specific error code to the client and abandons the request, restart will restart the transaction and increase the restart count.


There are certain actions you can perform on each subroutine when you customize Varnish:

Passes the request and its subsequent response to the backup server, without caching. You can call pass in both vcl_recv and in vcl_fetch.

The request is made from vcl_recv to deliver content from the cache although the petition indicates that it must be passed. You can call lookup from vcl_fetch.

From vcl_recv pipe short-circuits the client and backup connections, and Varnish simply it stays there passing the data to one side and another, recording the data, so the records will be incomplete. Be careful since an HTTP 1.1 client can send multiple requests on the same connection, and you could have Varnish add a " Connection: close " header before calling the connection stack.

] Delivery the object cached to the client. Normally the call is made from vcl_fetch .

Does an ESI process of the document purchased.

If you want to know more about VCL do not miss this tutorial which also contains functions that you can perform on your site.

Sample configurations

I hope you're learning something (or a lot) from Varnish, but the best way to start to play with is to see some sample configuration files .

The web of the Varnish community has a huge collection of sample configurations which are a good place to start doing yours. There are even some great sample configurations for WordPress from fetch and receive in Github .

I think that at this point it goes without saying that Varnish is very customizable and that can do wonders for any WordPress installation especially those with high traffic. Also, it must be recognized, it is not for anyone, at least you have to have knowledge of connection with servers through Linux.

The best thing is that, with little effort and free, you can configure a really powerful cache with Varnish, based on the user permissions, in the type of user or whatever you can think of.

If you want more evidence of the power of Varnish, not only WordPress Help uses it, too Facebook and I think there is no better high traffic web test than this tremendous social network do not you think?

WordPress plugins

There are, as I mentioned a few days ago, WordPress plugins that allow you to configure or manage the behavior of Varnish in WordPress, which you will find are these:

Well, do you dare to try Varnish or have you used it?

NOTICE : this publication is from two years ago or more. If it's a code or a plugin it might not work in the latest versions of WordPress, and if it's a news story it might be obsolete. Then do not say we have not warned you.

Loading …

That may also help you:

How to install WordPress from the Shell

Installing WordPress is easy but when you do in the usual way it's a really long process, where you have to interact with several windows, applications, you know: downloads the latest version, decompress it on your computer, open the ftp client to upload it, create the database in your hosting panel, edit the wp- file config.php with a text editor, and then return to the browser to start the installation of the system.

But there is a faster method in which you do not leave a single window, and if you hurry me, it's more effective. All you need is access to your server from Shell SSH and from the window of Command Terminal you can do everything. Also, you know that the terminal remembers the commands so it's not that complicated. What's more, if you use the Mac OS X Terminal you can even drag and drop the commands from this same tutorial to streamline the process.

Let's go …

1. Connect by SSH

First of all is open the command interface . If you are in Mac OS X simply type "terminal" in Spotlight and run the application, if you are in Windows better download the application Putty . Once the terminal window is open, connect to your server using the SSH protocol :

Change " user " by your SSH username and " " by the domain name of the server to which you want to connect or , if you prefer, the IP address assigned to the server. Press the ENTER key and you will be asked for the password. Enter your SSH password and press ENTER again (you will not see anything on the screen while typing). If you have not made a mistake in any data you will be in a moment inside your remote server.

Note: the user data usually coincide with your FTP username and the password will be provided by your hosting provider or it will be the same one with which you connect to your hosting panel, not to the CPanel or Plesk but to your account in the provider. If you have questions, ask your provider.

The next thing you have to do is go to the folder where your hosting is associated with the domain, where you will install WordPress. Check the absolute path of your server which, in many cases, is usually something like this:

The above route is typical in a server managed with Plesk (the one I use in Mediatemple) if you are going to install WordPress in the public folder. However, this route may vary so check this information in your accommodation panel.

Once you have entered the route, press ENTER and it will show you the ' prompt '. To make sure you're where you wanted to, type the following command:

2. WordPress Download

Once we are sure we have placed in the appropriate folder it is time to download the latest version of WordPress in that directory. Execute the following command to download the file: