This instruction is outdated as Helicon Zoo repository now include Magnolia CMS Community Edition, that you can easily install by choosing Zoo –> Applications –> Magnolia CMS.
First we need to configure our Windows server to run Java Servlet applications. Follow these steps to accomplish this task.
Alternatively, instead of installing Helicon Zoo Module and Jetty separately you may just go to Packages section of Zoo tab and install Java Hosting Package. This will install Helicon Zoo Module for IIS, Jetty and all other requirements to run Java Servlet applications under Microsoft IIS web server. If you want to run Java Servlets under IIS Express and WebMatrix in your development environment, then you need to install Helicon Zoo Module for IIS Express form Engines section.
This is enough configuration to run most of Java Servlet applications directly form IIS.
There are many ways to install Magnolia. Some of them you may find in the documentation. We are going to use a free Community edition which can be downloaded here sourceforge.net/projects/magnolia/files/magnolia/
Please download “magnolia-bundled-webapp…” package as it already contains required components to run Magnolia CMS. Open folder with latest version of CMS and download the .war file available. After downloading .war file, please launch IIS Manager and create new web-site or application. Copy downloaded .war file into this web-site’s root folder and create the following web.config near it:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<heliconZoo>
<application name="magnolia.project" >
<environmentVariables>
<add name="WAR_FILE" value="magnolia-bundled-webapp-4.5.1.war" />
<add name="WAR_EXTRACT_PATH" value="%APPL_PHYSICAL_PATH%" />
</environmentVariables>
</application>
</heliconZoo>
<handlers>
<add name="magnolia.project#x86" scriptProcessor="java.jetty" path="*" verb="*" modules="HeliconZoo_x86"
preCondition="bitness32" resourceType="Unspecified" requireAccess="Script" />
<add name="magnolia.project#x64" scriptProcessor="java.jetty" path="*" verb="*" modules="HeliconZoo_x64"
preCondition="bitness64" resourceType="Unspecified" requireAccess="Script" />
</handlers>
</system.webServer>
</configuration>
Please take a look at <environmentVariables> section. Only “WAR_FILE” variable is required and should contain either path to a WAR file or to a folder containing unpacked Java Servlet application.
WAR_EXTRACT_PATH variable can be used to configure location where to unpack WAR file content. By default it is IIS application root folder. CONTEXT_PATH variable needed by Java application and contains IIS application virtual path by default.
That’s it. You may now open the web-site in browser to start Magnolia. Please note, first launch is going to be long and will start with installation page:
Click “Start install” to begin installation:
When installation is complete, click “Start up Magnolia” and you’ll see login form. Enter default login “superuser” and password “superuser”.
Magnolia comes with demo data and templates:
As you can see we’ve installed Magnolia CMS easily in very few steps. Naturally you may deploy any .war file in the same way.
]]>
You can download SilverStripe from this page: http://www.silverstripe.com/silverstripe-web-application-framework/. After downloading please install CMS according to installation instructions provided by vendor.
Actually, SE-friendly feature is enabled by default. But SilverStripe does not originally support IIS and ISAPI_Rewrite. On the first page of the installation you may see this text:
If you open your web-site after SilverStripe installation, you will see the note that mod_rewrite is not enabled. Actually, SilverStripe tries to find mod_rewrite (only), and if the search is successful, SilverStripe automatically creates rules in .htaccess file, and you get CMS working with SE-friendly URLs!
Thus under IIS we need to do some hacking. Let’s just disable the check for mod_rewrite.
Please go to SilverStripe installation folder and open rewritetest.php file. Please find this code:
$testrewriting = file_get_contents($location);
if($testrewriting == 'OK') {
return true;
}
And comment is out as follows:
//$testrewriting = file_get_contents($location);
//if($testrewriting == 'OK') {
return true;
//}
So we just commented the check and left only return true and .htaccess configuration file required to run SEF URLs is already in place.
Done! Now you can use SilverStripe with pretty SE-friendly URLs powered by ISAPI_Rewrite.
You can download MW from this page: http://www.mediawiki.org/wiki/Download. After downloading please install MW according to installation instructions provided by the vendor.
Default MediaWiki URLs look like www.yousite.com/index.php?title=TITLE, but you can change them by using two configuration variables in LocalSettings.php:
$wgScript and $wgArticlePath.
In this article we will try to make
simple SEO-friendly urls like www.yousite.com/TITLE.
So, please open LocalSettings.php document (it is located in MediaWiki root folder) and append this code:
$wgScript = "";
$wgArticlePath = "$wgScript/$1";
Please note! The $wgScript variable must contain path to your MW folder. For example, if your MW installation is
C:\inetpub\wwwroot\mediawiki
,
then you must write $wgScript = "/mediawiki"
, or if your MW installation is
C:\inetpub\wwwroot\
, then you must write $wgScript = ""
.
Now please create .htaccess file in the installation folder of MediaWiki and put these rules into it:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?title=$1 [NC,L,QSA]
Done! Now you can use MediaWiki with pretty SE-friendly URLs.
]]>
You can download Drupal from official web site: http://drupal.org/. Please install Drupal according to installation instructions provided by vendor.
Please note! In the installation wizard you can see the configuration for enabling SE-friendly URLs, but with IIS you can’t use it because Drupal blocks controls as shown on this picture:
Please just leave it as is, it is possible to change this setting later.
Please find the file %PATH_TO_DRUPAL%/sites/default/settings.php, where %PATH_TO_DRUPAL% is the root of Drupal’s installation folder. Open this document and append the code given below:
$conf[ 'clean_url' ] = 1;
Then please open .htaccess file located in the root folder of Drupal. There are many rules but only some of them are intended for ISAPI_Rewrite, others are for Apache Web Server.
Please remove all rules from .htaccess file and put these:
RewriteEngine on
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Actually these are default Drupal rules for Apache mod_rewrite configuration and we just cut them from default .htaccess file.
Done! Now you can use Drupal CMS with pretty SEO-friendly URLs.
You can download WordPress from this web page: http://wordpress.org/download/.
Please don’t use versions lower than 2.6.1, because they will not work properly with ISAPI_Rewrite 3.
After downloading please install WordPress according to the installation instructions by the vendor. Note that in the installation wizard you may allow your blog to appear in search engines. This action enables indexing and will probably be important for you.
By default SE-friendly URLs are disabled. To enable this feature please go to WordPress administration panel. On the main page of administration panel please select “Settings” tab:
Now please select “Permalinks” tab. On the opened page you can see some default schemes of prettifying your URLs.
You may choose necessary scheme but notice that WordPress doesn’t use .htaccess file and ISAPI_Rewrite to process these permalinks. You will need to write your own rules.
Let’s write some simple rules for WordPress using ISAPI_Rewrite. Open “Permalinks” configuration as described above. Select “Custom Structure” radio box, and in adjacent field write /%post_id%/%postname% as shown on this picture:
Please save changes. %post_id% and %postname% are special tag names. You can read more about tags here: http://codex.wordpress.org/Using_Permalinks. So we have configuration for URLs like http://domain.com/1/my-great-post, and now we need to write some rules in .htaccess file. Please create .htaccess file in the root folder of WordPress and write the following code into it:
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(\d+)/[^/]+/?$ index.php?p=$1 [NC,L]
These rules rewrite requests like /1/my-great-post to those like index.php?p=1, but only if no such physical file of folder exist.
Done! Now you can use your WordPress blog with pretty URLs!
You can download Mambo from this page: http://mambo-code.org/gf/project/mambo/frs/. After downloading please install Mambo according to installation instructions provided by vendor.
By default SE-friendly URLs are disabled. To enable this feature please go to Mambo administration panel. On the main page of administration panel please select “Global Configuration”
On the opened page you can see few tabs. Please find “SEO” tab and select it:
Now you can see the configuration for SEO. Please select “yes” for option “Search Engine Friendly URLs”. Then apply and save your settings. Also please go to Mambo installation folder and rename htaccess.txt file to .htaccess.
Now all URLs on your site are SE-friendly. But the navigation will not work properly. It happens because Mambo uses variable $_SERVER[ ‘REQUEST_URI’ ] which is not supported by IIS.
You will need to make a little fix in the Mambo’s source code. Please copy this code to clipboard:
if ( isset( $_SERVER[ 'HTTP_X_REWRITE_URL' ] ) ) { $_SERVER[ 'REQUEST_URI' ] = $_SERVER['HTTP_X_REWRITE_URL' ]; }
Now you need to find index.php file in the root of Mambo installation folder. Please open this document with any editor and paste the above code at the top of index.php as shown on this picture:
Done! Now you can use Mambo CMS with pretty SE-friendly URLs. This article describes how to use Mambo with its default rules in .htaccess file, but of course you may replace them.
]]>You can download Joomla from official web site: http://joomla.org/download.html. After downloading please install Joomla according to installation instructions provided by vendor.
By default SE-friendly URLs are disabled. To enable this feature please go to the administration panel of Joomla. On the main page of administration panel please select “Global Configuration”
On the opened page you can see the group-box called “SEO Settings”. Please select “yes” for options “Search Engine Friendly URLs” and “Use Apache mod_rewrite”. Then apply and save your settings. Also please go to Joomla installation folder and rename htaccess.txt file to .htaccess.
Now all URLs on your site are SE-friendly. But there are some hurdles left. When you type different URLs in the address bar you always end up with the main page. It happens because Joomla uses variable $_SERVER[ ‘REQUEST_URI’ ] which is not supported by IIS.
You will need to add a little fix in the Joomla’s source code. Please copy this code to clipboard:
if ( isset( $_SERVER[ 'HTTP_X_REWRITE_URL' ] ) ) { $_SERVER[ 'REQUEST_URI' ] = $_SERVER['HTTP_X_REWRITE_URL' ]; }
Now you need to find index.php file in the root of Joomla installation folder. Open this document with any editor supporting Unix format (e.g. WordPad). Note: you can’t use Notepad to edit index.php because Notepad does not support saving in Unix format. Paste code above at the top of index.php as shown on this picture:
Done! Now you can use Joomla CMS with pretty SE-friendly URLs. This article describes how to use Joomla with its default rules in .htaccess file but of course you may replace them.
]]>
After MySQL installation run MySQL Command Line Client and execute the following command:
create database farcrydatabase;
Install Adobe ColdFusion.Make sure ColdFusion is registered in IIS:
Download the latest version of FarCry CMS.
Unzip the installation package to C:\inetpub\wwwroot\farcry
.
Create your project.
Specify project name, project folder and locale.
Select the FarCry CMS Datasource previously created in ColdFusion Administrator area.
Note: create your Datasource in ColdFusion Administrator area as shown below:
Standard FarCry URL looks like: index.cfm?objectid=E689D722-06DF-6D24-56726E44740068B5
. Not a friendly URL at all…
After installation login to FarCry Administrator area, choose the Site section and Current Friendly URLs tab in the right side menu.
Click Manage button and add your SEO URL. Set Type of redirection to None and Redirect to to To the default FU because we don’t need a redirect, we only need to show the content of the real page.
We’ve just added friendly URL for our Support page but FarCry CMS says it is still not working.
We can check it by entering our SEO-friendly URL into the browser’s address bar:
Now we’ll eliminate this problem using Helicon APE.Download and install the latest version of Helicon APE.Launch Helicon APE and add these lines to .htaccess file in the root of your site:
RewriteEngine On
RewriteCond %{REQUEST_URI} !(^/farcry|^/webtop|^/flex2gateway|^/flashservices|^/cfide)($|/)
RewriteRule ^([^.]+)$ index.cfm?furl=/$1 [L,NC,QSA]
Save the config.
To make FarCry CMS apply these rules ColdFusion server needs to be restarted. So, go to ColdFusion installation folder (C:\ColdFusion8\) -> /bin/ and launch cfstop.bat file. Then start your ColdFusion server by launching cfstart.bat file.
Now in Administrator area we can see that FarCry CMS has applied SEO-friendly URLs.
Visit your site to make sure that it is really true.
If the result resembles the one above, extend our congratulations – you’ve just set up SEO-friendly URLs for your FarCry site.
Regards,
HeliconTech Team
After MySQL installation run MySQL Command Line Client and execute the following command:
create database wordpress;
Install PHP into C:\inetpub\php
to inherit NTFS permissions of IIS directory. It is of importance that C:\inetpub\php\php.ini
contained the following directives:
magic_quotes_runtime = Off
extension_dir = "C:\inetpub\php\ext\"
extension=php_mysql.dll
After ensuring the directives are in place you need to register PHP in IIS configuration. To accomplish this:
Download the latest WordPress version
Unzip the package into C:\inetpub\wwwroot\wordpress
Rename wp-config-sample.php
into wp-config.php
.
Adjust MySQL connection:
Create a blog
Now in Administrative panel you can set SEO-friendly format for your links, e.g: /%post_id%/%postname%
Your links will now look like http://localhost/wordpress/2008/uncategorized/hello-world
instead of http://localhost/wordpress/?p=123
. If you now attempt to access any of the pages on your blog,
you’ll get 404 Not Found error
And that is defenitely not the desired result!
It’s time to fix the above inconveniences and accelerate WordPress.
We’ll use the following Helicon Ape modules:
It’ll assist us in handling SEO-friendly URLs.
Open Helicon Ape Manager and uncomment/add the following line in httpd.conf to enable mod_rewrite:
LoadModule rewrite_module modules/mod_rewrite.so
Now in Helicon Ape Manager browse to WordPress folder and put the following code to .htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php?$1 [L,QSA]
This piece of code checks whether the requested resource is physically located on the disk and if it doesn’t, performs rewriting to index.php.
Save changes to .htaccess. Request any blog page once again… It works!
Yes, it does… but not the best way… So we are moving on! ‘Cause only the best is good enough:)
With this module we’ll adjust browser cache so that the browser doesn’t send excess requests to the server. Go back to httpd.conf in Helicon Ape Manager and uncomment/add the following line:
LoadModule expires_module modules/mod_expires.so
Subsequent lines (being put to .htaccess) will tell browser cache that images, css and JavaScripts must not be requested from the server (but rather taken from cache) within 1 day after retrieving resource for the first time:
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 days"
ExpiresByType image/gif "access plus 1 days"
ExpiresByType text/css "access plus 1 days"
ExpiresByType application/x-javascript "access plus 1 days"
Let’s check what’s changed. The first request grabs all page resources and for each image, css and JavaScript sets the header Cache-Control: max-age=86400
Upon consequent requests to that page the browser does not ask for images, css and JavaScripts from the server but takes them from the cache until max-age expires.
Are you enjoying the process? Then let’s implement the next stage. To make things even better, let’s apply on-the-fly compression that will reduce traffic and speed up page load. In our irreplaceable Helicon Ape Manager please uncomment/add the following line inside httpd.conf:
LoadModule gzip_module modules/mod_gzip.so
And put the following lines into .htaccess in WordPress folder:
mod_gzip_on yes
mod_gzip_item_include Mime ^text/.*
These directives instruct Helicon Ape to compress only those resources which type starts with “text/”, i.e. all text, .html and .css files. Usually images and video compression is useless.
Uncompressed page had Content-Length: 5152
, the same page after compression became as small as Content-Length: 2168
. So, we’ve managed to reduce the amount of info to be transferred almost twice.
We are coming to the final and in conclusion we’ll enable server-side caching. Instead of requesting the same page from the server again and again Helicon Ape saves the copy of server response and fires with it when corresponding page is needed.
Uncomment/add the following line in httpd.conf (using Helicon Ape Manager):
LoadModule cache_module modules/mod_cache.so
We’ll only cache index.php page. It will be stored in cache for 30 seconds so that the site looked dynamic. There’s no need to cache static files (.html, .css, images, Flash, videos) because IIS processes them really fast.
Note! It is worth mentioning that cache distinguishes query string parameters, thus it will store different snapshots for different blog pages.
There are some shortcomings of this type of caching (semi-dynamic web application). E.g. if the user posts a comment on the blog, it will see the result (his post) immediately, but another user browsing this page will only see it in 30 seconds (after cache expires). This issue may be resolved by reducing the time snapshot lives in cache, but it should nevertheless be taken into account.
Put the following lines into .htaccess in WordPress folder:
<Files index.php>
ExpiresByType "text/html; charset=UTF-8" A30
CacheEnable mem
CacheVaryByHeaders Original-Url
</Files>
Let us compare the productivity with and without cache. On our testing virtual machine we’ve obtained the following values:
The last drop we want to add to our WordPress-based dish will hide IIS from robots and scanners.
You need to uncomment/add the following line in httpd.conf:
LoadModule headers_module modules/mod_headers.so
And put the only line into .htaccess:
Header set Server "Apache/2.2.9 (Unix)"
Now our IIS appears to the world like
Congratulations to everyone who came to finish! It’s all done now! Enjoy flawless and fast WordPress operation and stay with us!
Best regards,
Helicon Team.
]]>