February 26, 2009 at 11:27 Multi WordPress
Conditions of the problem:
Solution:
I had to abandon the very tempting idea to breed on the MaxSite CMS site right away, due to the lack of remote publishing capabilities so far. More precisely, it is already present, but developed according to the author’s standards and with his own client for Windows.
The next simple solution was to breed Wordpress. Since one of the most important things that any normal programmer with the first bytes absorbs is code reuse, he also abandoned this idea. Imagine thirty WP installations, follow the updates of each of them, edit topics in different directories, follow the updates of each plugin of each blog. All this will result in writing an automated update system with a general complication of the entire system as a whole 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 technologies OpenID , Trackback, and many others first appeared . One of the main advantages of Movable Type is the static publishing of content. That is, pages are not generated for the user by scripts at the time of access to the server, but are created as good old html-files. One installation of the system is theoretically capable of serving thousands of blogs on different domains, subdomains, subdirectories - everywhere within the server file system. Since the pages will be static - the server will survive the Digg effect.
From the main advantage, the main disadvantages follow. When publishing a blog or completely republishing in the event of a design change, you will be doomed to spend hours looking at posts like: “Publishing a record 2 of 7890.”
Admin is slow . Extremely slow. Using shared hosting turned out to be extremely difficult. Difficulties also arose with comments - since the hoster did not give access to httpd.conf, it was not possible to register aliases for scripts.
Started experimenting with Wordpress MU- multi-user edition. Installation problems arose no less than with the Movable Type. The fact is that MU is designed for blogs in either subdirectories or subdomains. But with the work on separate domains, again, a problem arises. The solutions found using plugins were not without problems . Another solution also involved editing httpd.conf ... The final solution, as always, was simple and elegant .
Install regular Wordpress once on one of the domains, and make the rest of the 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 of the form md5 ($ _ SERVER ['HTTP_HOST']. $ Salt) or even by conditions.
One more clue. When integrating an existing blog into this assembly, you will definitely have problems with access to the admin panel. In this case, rename the option name “wp_user_roles” in the prefix_options table to “prefix_user_roles”, and in the prefix_usermeta table, rename all options starting with the old “wp_” prefix in the same way.
Conditions of the problem:
We have one domain on which Wordpress is installed and several domain aliases (synonyms) to it. Well, for example, domain.ru as the main domain and alias.ru as its alias. So, following the link http://domain.com/wp-admin we get into the admin panel of the first blog. Accordingly, following the link alias.ru/wp-admin we get to the admin panel of the second blog? Nothing of the sort, for some reason we again find ourselves in the admin panel of the first blog. Understand what is the matter.
Solution:
The problem stems from the features of the Apache mod_dir module. Excerpt from the documentation :
The bottom line is that if a request is made for a directory, not a file on the server and the request does not end with a slash, the module will automatically redirect the request to the same address, but adding a slash at the end. This is not a bug, this is a very inconvenient feature. It is called trailing slash redirect .
And in the case of an alias domain, it is at the same time and replaces the alias name with the name of the main domain. Therefore, if we add a slash to the second request, then we get to the admin panel of the second blog, and if not, then we are transferred to the admin panel of the first.
For a final solution to the issue, you need to make some changes to all of our favorite .htaccess file. In my case, it was generated by Wordpress when the options for showing the CNC (human-friendly URLs) were turned on and looked like this: The .htaccess syntax is quite simple. Directive
RewriteEngine On means that we have enabled the processing of the transformation mechanism. RewriteBase is the base URL for translations relative to this directory.
RewriteCond - these are the conditions of transformations, the logic of work. The first parameter is the string to compare, the second is the condition. As compared strings server variables are usually used. For example - REQUEST_FILENAME path to the requested file in the server file system. The condition ! -F means that the request is not a file , and ! -D means that it is not a directory. Accordingly, two lines of RewriteCondtell the module that the next steps should be performed if a non-real file or directory is requested.
RewriteRule is the conversion rule itself. It will be fulfilled in our case if the two conditions of RewriteCond are true. The syntax is simple - the first parameter is a template, the second is a substitution. In the template, we have access to the full power of Perl regular expressions, without knowing which it is better not to meddle in web development. Moreover, their study in the required volume will not take more than a day.
So, we add two more conditions: The first, as already understood, is true if the request leads to a directory. The second uses two more server variables - REQUEST_URI - the request itself and HTTP_HOST
- server name. The second condition is true if the request is not equal to the server name. That is, if the request leads to a server subdirectory, then the condition is also true.
Now add the redirect rule.
The template uses a simple regular expression. ^ And $ indicate test at the beginning and end of the string . - checking for any character, quantifier + , unlike quantifier * (Wedge stars), expresses one or more copies of the previous expression, thus . + Means any arbitrarily long sequence of characters, more than one. Square brackets [] - define a character class, and ^ declares an exclusive class. Thus[^ /] - the exclusive literal character class / .
The whole expression means: a string starts with any character 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. A rule replacement template has been created. Now consider what we replace this line with.
The http: // prefix is clear, the server name variable too. / here they mean themselves, but with $ 1 more interesting.
$ X is a feedback from the RewriteRule directive that provides access to the grouped parts of the RewriteRule pattern with 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 a backslash to the name of the server / this request . closing just / - mod_dir is satisfied, and we can get into the admin panel.
- Create several blogs of the same type.
- Blogs must support remote publishing.
Solution:
I had to abandon the very tempting idea to breed on the MaxSite CMS site right away, due to the lack of remote publishing capabilities so far. More precisely, it is already present, but developed according to the author’s standards and with his own client for Windows.
The next simple solution was to breed Wordpress. Since one of the most important things that any normal programmer with the first bytes absorbs is code reuse, he also abandoned this idea. Imagine thirty WP installations, follow the updates of each of them, edit topics in different directories, follow the updates of each plugin of each blog. All this will result in writing an automated update system with a general complication of the entire system as a whole 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 technologies OpenID , Trackback, and many others first appeared . One of the main advantages of Movable Type is the static publishing of content. That is, pages are not generated for the user by scripts at the time of access to the server, but are created as good old html-files. One installation of the system is theoretically capable of serving thousands of blogs on different domains, subdomains, subdirectories - everywhere within the server file system. Since the pages will be static - the server will survive the Digg effect.
From the main advantage, the main disadvantages follow. When publishing a blog or completely republishing in the event of a design change, you will be doomed to spend hours looking at posts like: “Publishing a record 2 of 7890.”
Admin is slow . Extremely slow. Using shared hosting turned out to be extremely difficult. Difficulties also arose with comments - since the hoster did not give access to httpd.conf, it was not possible to register aliases for scripts.
Started experimenting with Wordpress MU- multi-user edition. Installation problems arose no less than with the Movable Type. The fact is that MU is designed for blogs in either subdirectories or subdomains. But with the work on separate domains, again, a problem arises. The solutions found using plugins were not without problems . Another solution also involved editing httpd.conf ... The final solution, as always, was simple and elegant .
Install regular Wordpress once on one of the domains, and make the rest of the 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 of the form md5 ($ _ SERVER ['HTTP_HOST']. $ Salt) or even by conditions.
One more clue. When integrating an existing blog into this assembly, you will definitely have problems with access to the admin panel. In this case, rename the option name “wp_user_roles” in the prefix_options table to “prefix_user_roles”, and in the prefix_usermeta table, rename all options starting with the old “wp_” prefix in the same way.
Conditions of the problem:
We have one domain on which Wordpress is installed and several domain aliases (synonyms) to it. Well, for example, domain.ru as the main domain and alias.ru as its alias. So, following the link http://domain.com/wp-admin we get into the admin panel of the first blog. Accordingly, following the link alias.ru/wp-admin we get to the admin panel of the second blog? Nothing of the sort, for some reason we again find ourselves in the admin panel of the first blog. Understand what is the matter.
Solution:
The problem stems from the features of the Apache mod_dir module. Excerpt from the documentation :
The index of a directory can come from one of two sources:
* A file written by the 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.
The two functions are separated so that you can completely remove (or replace) automatic index generation should you want to.
A "trailing slash" redirect is issued when the server receives a request for a URL servername / foo / dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to servername / foo / dirname .
The bottom line is that if a request is made for a directory, not a file on the server and the request does not end with a slash, the module will automatically redirect the request to the same address, but adding a slash at the end. This is not a bug, this is a very inconvenient feature. It is called trailing slash redirect .
And in the case of an alias domain, it is at the same time and replaces the alias name with the name of the main domain. Therefore, if we add a slash to the second request, then we get to the admin panel of the second blog, and if not, then we are transferred to the admin panel of the first.
For a final solution to the issue, you need to make some changes to all of our favorite .htaccess file. In my case, it was generated by Wordpress when the options for showing the CNC (human-friendly URLs) were turned on and looked like this: The .htaccess syntax is quite simple. Directive
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteEngine On means that we have enabled the processing of the transformation mechanism. RewriteBase is the base URL for translations relative to this directory.
RewriteCond - these are the conditions of transformations, the logic of work. The first parameter is the string to compare, the second is the condition. As compared strings server variables are usually used. For example - REQUEST_FILENAME path to the requested file in the server file system. The condition ! -F means that the request is not a file , and ! -D means that it is not a directory. Accordingly, two lines of RewriteCondtell the module that the next steps should be performed if a non-real file or directory is requested.
RewriteRule is the conversion rule itself. It will be fulfilled in our case if the two conditions of RewriteCond are true. The syntax is simple - the first parameter is a template, the second is a substitution. In the template, we have access to the full power of Perl regular expressions, without knowing which it is better not to meddle in web development. Moreover, their study in the required volume will not take more than a day.
So, we add two more conditions: The first, as already understood, is true if the request leads to a directory. The second uses two more server variables - REQUEST_URI - the request itself and HTTP_HOST
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_URI} !^%{HTTP_HOST}$- server name. The second condition is true if the request is not equal to the server name. That is, if the request leads to a server subdirectory, then the condition is also true.
Now add the redirect rule.
RewriteRule ^(.+[^/])$ %{HTTP_HOST}/$1/ [R]The template uses a simple regular expression. ^ And $ indicate test at the beginning and end of the string . - checking for any character, quantifier + , unlike quantifier * (Wedge stars), expresses one or more copies of the previous expression, thus . + Means any arbitrarily long sequence of characters, more than one. Square brackets [] - define a character class, and ^ declares an exclusive class. Thus[^ /] - the exclusive literal character class / .
The whole expression means: a string starts with any character 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. A rule replacement template has been created. Now consider what we replace this line with.
The http: // prefix is clear, the server name variable too. / here they mean themselves, but with $ 1 more interesting.
$ X is a feedback from the RewriteRule directive that provides access to the grouped parts of the RewriteRule pattern with 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 a backslash to the name of the server / this request . closing just / - mod_dir is satisfied, and we can get into the admin panel.