Multivordpressing
Conditions of the problem:
Decision:
MaxSite CMS had to abandon the very tempting idea of ​​breeding at the site immediately, due to the lack of remote publishing capabilities in it so far. More precisely, it is already present, but developed by the standards of the author and with his own client under Windows.
The next simplest solution was Wordpress. Since one of the main things that any normal programmer with the first bytes absorbs is the reuse of code, he also refused this idea. Imagine - thirty installations of WP, follow the updates of each of them, edit topics in different directories, follow the updates of each plug-in of each blog. All of this will result in the writing of an automated update system with a general complication of the entire system and an unacceptable amount of time.
So I came to the Movable Type . The platform is written in perl and is a trendsetter: it was in it that the technology OpenID , Trackback and many others first appeared. One of the main advantages of Movable Type is static content publishing. That is, the pages are not generated for the user by the scripts at the time of accessing the server, but are created as good old html files. One installation of the system is theoretically capable of serving thousands of blogs in different domains, subdomains, subdirectories - everywhere within the server's file system. Since the pages will be static - Digg effect the server will survive.
The main disadvantages are the main disadvantages. When publishing a blog or full republishing if you change the design, you will be doomed for hours to look at posts like: “Publish Record 2 out of 7890.”
Admin works slowly . Very slowly. On a virtual hosting it turned out to be extremely difficult to use. Difficulties arose with comments - since the hoster did not give access to httpd.conf, it was not possible to register aliases for the scripts.
Began to experiment with Wordpress MU - a multi-user edition. Problems with the installation arose no less than with Movable Type. The fact is that MU is designed for blogs either in subdirectories or in subdomains. But with the work on individual domains, again, there is a problem. Found solutions using plug-ins were not without problems . Another solution also suggested editing httpd.conf ... The final solution, as always, was simple and elegant .
Install a regular Wordpress to one of the domains once, and make the remaining domains aliases. In the config, change the hard prefix of the table names MySql c 'wp_' to dynamic, created on the basis of $ _SERVER ['HTTP_HOST']. The found piece of code looked like this:
I just replaced str_replace with ereg_replace (“www \. | \ - | \.”, ””, $ Prefix).
In the paranoid version, you can specify prefixes like md5 ($ _ SERVER ['HTTP_HOST']. $ Salt) or by conditions.
Another clue. When integrating an existing blog into this build, there will be problems with access to the admin panel. In this case, in the prefix_options table, rename the name of the option “wp_user_roles” to “prefix_user_roles”, and in the table “prefix_usermeta” rename all options starting with the old prefix “wp_” in the same way.
Conditions of the problem:
We have one domain on which Wordpress is installed and several alias domains (synonyms) to it. Well, for example, domain.ru as the main domain and alias.ru as its alias. So, following the link http://domain.ru/wp-admin get into the admin panel of the first blog. Accordingly, following the link alias.ru/wp-admin we get into the admin panel of the second blog? Nothing like that, for some reason we again find ourselves in the admin of the first blog. Understand what's the matter.
Decision:
The problem stems from the peculiarities of the apache mod_dir module. Excerpt from the documentation :
The bottom line is that if there is a request for a directory, not a file on the server and the request does not end in a slash, the module automatically forwards the request to the same address, but adding a slash at the end. This is not a bug, this is a very uncomfortable feature. It is called trailing slash redirect .
And in the case of a domain alias, it also replaces the alias name with the name of the main domain. Therefore, if we add a slash to the second request at the end, we will get into the admin panel of the second blog, and if not, we will be transferred to the admin panel of the first one.
For the final solution of the issue, it is necessary to make some changes to all of us favorite .htaccess file. In my case, it was generated by Wordpress when the CNC display options were turned on (by human readable URLs) and it looks like this:
The .htaccess syntax is pretty simple. The directive RewriteEngine On means that we have enabled processing of the transformation mechanism. RewriteBase is the base URL for conversions relative to a given directory.
RewriteCond - is the conditions of transformation, the logic of work. The first parameter is the compared string, the second is the condition. As comparison strings, server variables are usually used. For example - REQUEST_FILENAME is the path to the requested file in the server file system. The condition ! -F means that the request is not a file, and ! -D - which is not a directory. Accordingly, the two lines of the RewriteCond tell the module that subsequent actions should be performed if a non-existent file or directory is requested.
RewriteRule is the conversion rule itself. It will be executed in our case, if two conditions of RewriteCond are true. The syntax is simple - the first parameter is the pattern, the second is the substitution. In the template, we have access to all the power of Perl regular expressions, without whose knowledge it is better not to go into web development. Moreover, more than a day of their study in the required amount will not take.
So, we add two more conditions:
The first, as already understood, is true if the request leads to a directory. In the second, two more server variables are used - REQUEST_URI - the request itself and HTTP_HOST - the server name. The second condition is true if the request is not equal to the server name. That is, if the request leads to the server subdirectory, then the condition is also true.
Now add the redirect rule.
The pattern uses a simple regular expression. ^ and $ mean checks for the beginning and end of the line ,. - checking for any symbol, quantifier + in contrast to quantifier * (Klin stars) expresses one or more copies of the previous expression, thus . + Means any arbitrarily long sequence of characters, with a number greater than one. Square brackets [] - define a character class, and ^ declares an exclusive class. Thus [^ /] is the exclusive literal character class / .
The whole expression means: the line begins with any character number from one to infinity and ends with any character that is not a literal / . That is just a string that does not end with a slash. Rule replacement template created. Now consider what we replace this line.
The http: // prefix is ​​clear, the server name variable too. / here mean themselves, but with $ 1 more interesting.
$ X is the feedback directive of the RewriteRule directive, providing access to the grouped parts of the RewriteRule pattern with the sequence number X. They are grouped by parentheses, in our case the first and only group is (. + [^ /]) .
As a result, the rule throws any request that is a request to an existing directory, but not limited to backslash in the name of the server / this request . closing just / - mod_dir is happy, and we can get into the admin panel.
- Create multiple blogs of the same type.
- Blogs must support remote publishing.
Decision:
MaxSite CMS had to abandon the very tempting idea of ​​breeding at the site immediately, due to the lack of remote publishing capabilities in it so far. More precisely, it is already present, but developed by the standards of the author and with his own client under Windows.
The next simplest solution was Wordpress. Since one of the main things that any normal programmer with the first bytes absorbs is the reuse of code, he also refused this idea. Imagine - thirty installations of WP, follow the updates of each of them, edit topics in different directories, follow the updates of each plug-in of each blog. All of this will result in the writing of an automated update system with a general complication of the entire system and an unacceptable amount of time.
So I came to the Movable Type . The platform is written in perl and is a trendsetter: it was in it that the technology OpenID , Trackback and many others first appeared. One of the main advantages of Movable Type is static content publishing. That is, the pages are not generated for the user by the scripts at the time of accessing the server, but are created as good old html files. One installation of the system is theoretically capable of serving thousands of blogs in different domains, subdomains, subdirectories - everywhere within the server's file system. Since the pages will be static - Digg effect the server will survive.
The main disadvantages are the main disadvantages. When publishing a blog or full republishing if you change the design, you will be doomed for hours to look at posts like: “Publish Record 2 out of 7890.”
Admin works slowly . Very slowly. On a virtual hosting it turned out to be extremely difficult to use. Difficulties arose with comments - since the hoster did not give access to httpd.conf, it was not possible to register aliases for the scripts.
Began to experiment with Wordpress MU - a multi-user edition. Problems with the installation arose no less than with Movable Type. The fact is that MU is designed for blogs either in subdirectories or in subdomains. But with the work on individual domains, again, there is a problem. Found solutions using plug-ins were not without problems . Another solution also suggested editing httpd.conf ... The final solution, as always, was simple and elegant .
Install a regular Wordpress to one of the domains once, and make the remaining domains aliases. In the config, change the hard prefix of the table names MySql c 'wp_' to dynamic, created on the basis of $ _SERVER ['HTTP_HOST']. The found piece of code looked like this:
$prefix = $_SERVER["HTTP_HOST"];
$prefix = str_replace("www.", "", $prefix);
$prefix = str_replace("-", "", $prefix);
$prefix = str_replace(".", "", $prefix);
$table_prefix = $prefix."_" ; //"wp_";
I just replaced str_replace with ereg_replace (“www \. | \ - | \.”, ””, $ Prefix).
In the paranoid version, you can specify prefixes like md5 ($ _ SERVER ['HTTP_HOST']. $ Salt) or by conditions.
Another clue. When integrating an existing blog into this build, there will be problems with access to the admin panel. In this case, in the prefix_options table, rename the name of the option “wp_user_roles” to “prefix_user_roles”, and in the table “prefix_usermeta” rename all options starting with the old prefix “wp_” in the same way.
Conditions of the problem:
We have one domain on which Wordpress is installed and several alias domains (synonyms) to it. Well, for example, domain.ru as the main domain and alias.ru as its alias. So, following the link http://domain.ru/wp-admin get into the admin panel of the first blog. Accordingly, following the link alias.ru/wp-admin we get into the admin panel of the second blog? Nothing like that, for some reason we again find ourselves in the admin of the first blog. Understand what's the matter.
Decision:
The problem stems from the peculiarities of the apache mod_dir module. Excerpt from the documentation :
The following is a directory of sources of information:
')
* A file written by user, typically called index.html. The DirectoryIndex directive sets the name of this file. This is controlled by mod_dir.
* Otherwise, a listing generated by the server. This is provided by mod_autoindex.
Can be completely removed (or replace).
A "trailing slash" is a URL for a URL servername / foo / dirname where the dirname is a directory. Directories require a trailing slash, mod_dir issues a redirect to servername / foo / dirname .
The bottom line is that if there is a request for a directory, not a file on the server and the request does not end in a slash, the module automatically forwards the request to the same address, but adding a slash at the end. This is not a bug, this is a very uncomfortable feature. It is called trailing slash redirect .
And in the case of a domain alias, it also replaces the alias name with the name of the main domain. Therefore, if we add a slash to the second request at the end, we will get into the admin panel of the second blog, and if not, we will be transferred to the admin panel of the first one.
For the final solution of the issue, it is necessary to make some changes to all of us favorite .htaccess file. In my case, it was generated by Wordpress when the CNC display options were turned on (by human readable URLs) and it looks like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>The .htaccess syntax is pretty simple. The directive RewriteEngine On means that we have enabled processing of the transformation mechanism. RewriteBase is the base URL for conversions relative to a given directory.
RewriteCond - is the conditions of transformation, the logic of work. The first parameter is the compared string, the second is the condition. As comparison strings, server variables are usually used. For example - REQUEST_FILENAME is the path to the requested file in the server file system. The condition ! -F means that the request is not a file, and ! -D - which is not a directory. Accordingly, the two lines of the RewriteCond tell the module that subsequent actions should be performed if a non-existent file or directory is requested.
RewriteRule is the conversion rule itself. It will be executed in our case, if two conditions of RewriteCond are true. The syntax is simple - the first parameter is the pattern, the second is the substitution. In the template, we have access to all the power of Perl regular expressions, without whose knowledge it is better not to go into web development. Moreover, more than a day of their study in the required amount will not take.
So, we add two more conditions:
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_URI} !^%{HTTP_HOST}$The first, as already understood, is true if the request leads to a directory. In the second, two more server variables are used - REQUEST_URI - the request itself and HTTP_HOST - the server name. The second condition is true if the request is not equal to the server name. That is, if the request leads to the server subdirectory, then the condition is also true.
Now add the redirect rule.
RewriteRule ^(.+[^/])$ %{HTTP_HOST}/$1/ [R]The pattern uses a simple regular expression. ^ and $ mean checks for the beginning and end of the line ,. - checking for any symbol, quantifier + in contrast to quantifier * (Klin stars) expresses one or more copies of the previous expression, thus . + Means any arbitrarily long sequence of characters, with a number greater than one. Square brackets [] - define a character class, and ^ declares an exclusive class. Thus [^ /] is the exclusive literal character class / .
The whole expression means: the line begins with any character number from one to infinity and ends with any character that is not a literal / . That is just a string that does not end with a slash. Rule replacement template created. Now consider what we replace this line.
The http: // prefix is ​​clear, the server name variable too. / here mean themselves, but with $ 1 more interesting.
$ X is the feedback directive of the RewriteRule directive, providing access to the grouped parts of the RewriteRule pattern with the sequence number X. They are grouped by parentheses, in our case the first and only group is (. + [^ /]) .
As a result, the rule throws any request that is a request to an existing directory, but not limited to backslash in the name of the server / this request . closing just / - mod_dir is happy, and we can get into the admin panel.
Source: https://habr.com/ru/post/52211/
All Articles