Configuring Staticizer is easy. After installing the last version of the plugin go to the plugin administrator and look for it. To simplify its location you may filter by name using something like 'stat' in the filter control. When found select it to open the main configuration screen:
At the right we have the following parameters:
Static Domain Name
This will be tha name that will substitute the domain where you are loading the pagre from. It may or may not include the scheme. If you include the scheme (http://, https://, ftp://, etc) then this value will substitute the existing scheme of the page. If you do not want this to happen simply write the destination domain like static.doymer.com without scheme. If you want to know more abour serving static content you may search the web or read this article.
If your site is not associated to the root folder of your web server then your URLs could be like http://www.mysite.com/myfolder/index.php. If this is not the same in your static site the basic substitution of the host name will end up with http://static.mysite.com/myfolder/index.php that could result an invalid path. So that if you write in this paremater 'myfolder' that word will be deleted from your path if it is the very first that exist in it obtaining a final URL like http://static.mysite.com/index.php.
You may consider this parameter as an SUBSTRACTIVE element for the final path. Take into account that if 'myfolder' appear in any other place of your path it wil not be deleted. So you may have paths like images/myfloder/imagen.png without further trouble.
Include stylesheet refs.
As it name implies here you select if you want to swap any reference to style sheets files.
Include script refs.
Include image refs.
In this case indicate if you want to swap any reference to images of your site.
If you do not input any alternate domain name or you select none of this three last options the plugin will change nothing. And remember to activate the plugin or it will do nothing too.
If you have it activated then you may show it is by inserting somewhere in your page a button like those that exist in pages to indicate that the page is CSS valid or XHTML valid. We propose the following one to show that your page minds to serve static content from a cookieless domain. Read this if you want to install it.
How does it work
- <script src .js>, for javscript files
- <link href .css>, for stylesheet files
- <img src .jpg o .png o .gif o .ico>, for images
Staticizer does not process script or css entries that are embeded in the page. Each one of the patterns located are then processed to see if the refer to the same domain that the current page. If this is the case then the interesting piece is selected and updated with the scheme if we have defined an alternate one, the domain where to redirect the request and the path if we we have written a folder to delete. This new URL replace the one located and it starts over with the next one.
Efficiency has been the main goal at desing time. Plugin chaining require that efficiency must be the main goal in their design to avoid starving the resources of the system. Because of this the selection of ALL the pieces we are interested in is done in Staticizer in a single pass of the page content and this fact puts a limit in what we might search for because some of the requirements to find out every single reference to an static element drive us to contradictory patterns that cannot be consolidated in a single one.
At this point we have to decide between making more passes of left some references out of the process. Given the fact that these left elements represent a very low percentage of all static elements existing in the page we have chosen to make a single pass and discard them. Anyway this is subject to change if it can be demonstrated that this discarding is not so insignificant as we have observed or we find a way to consolidate new patterns into the main expression.
As we already have explained it has not been possible to capture all desired patterns in a single pass and we have sacrified some of them looking after process speed. The use of this methodology to locate the interesting areas of the page has its drawbacks. It requires that our files have fixed extensions and that they are those we have included in the pattern. This should not be a problem because usually this is that way already. But if this is not your case that references will not be captured.
Other patterns have been tested but none of them has been as efficient as the one used but if anyone has an alternate proposal we will be glad to listen to.
In a Joomla! install there may coexist other system plugins that also make updates of the page contents. From former description about the inners of Staticizer we may deduce that the point in time where the plugin process the page is quite important. If after being processed by Staticizer some other contents is added it will not, logically, get updated.
Because of this staticizer should be positioned below these first and above those last. To achieve this you may have to use the ordering number of system plugins. Select 'system' as the type in the available plugin listing and put Staticizer in the desired position. May be you have to make a couple of tries before finding the right position. Like Jedis do, 'look at the source' code of the page to see if the result meets your expectations.
With our actual patterns some embeded URLs are not detected and, thus, not transformed. Right now we know that these are ignored:
- Embeded style images. As in <div style="background: url()>"
We expect that you may help us to detect any other that may exist.
My static domain also has cookies
Have a look at the cookies it contain, are they like __utm[x] or __utma and __utmz? This mean that your pages contain tracking cookies by Google Analytics. The code that Google propose has the bad habit of associate cookies with the root domain even if you are including it in a subdomain. If your static site is a subdomain of the same root domain as we told in this article we have discussed before then it will have attached the same Google Analytics cookies. You may avoid that by using a different domain or, if you do not want to spend your money in another domain, by limiting the scope of the Google cookies to the specific domain you are serving by means of the function _setDomainName of the pageTracker object. Search in the Google documentation how to do this. You will see it quite easy.
Google Analytics cookies have a very long lifetime so they are not going to disappear by themselves. You must delete all those associated to the root domain of your site from your browser by hand if you want to fix the problem definitively. The next image shows one of these cookies where you can see that it is associated to all those (sub)domains belonging to the doymer.com root and that it does not expire until more than 6 months in the future.
As each browser has its own way to handle cookies we are not going to explain here any of them. Anyway you should check the cookies you have and delete those you do not want to have. You can delete all them but this way you may delete some one that you may want to keep or that you need to keep so this is not the recommended solution.
If cookies have a different name then you will have to investigate which may be the reason. Request an image directly served by your static domain, Does it have cookies this time?
Page Optimizers keep saying that I need to serve the static content from a cookieless domain
Read the former point
There are still static elements in my pages
This is because those elemenst were not in the page when Staticizer picked it up, well because they have been added later (read the part that explain the execution order) well because they are references that are included in the stylesheet files. Most probably is that they are associated with your template. Look at the code of your page and try to deduce the source of the problem. If it is a problem of execution order then try to adjust it again to get the plugin that is adding those content executed before Staticizer does. If it is a problem of your template you will have to edit by hand the culprit css file.
If you have decided you will like to add to your page the proposed logo then you will need to work a bit the template where you are adding it. You may start by downloading the picture of the button and saving it somewhere in your site (we suggest the images folder of your current template). To download the button it is enough to click with the right button of your mouse over it and select 'Save image as...'
Now you have to add in your template the following code to make the button appear. If you did not save it in the 'images' folder of your current template be careful to update the value of '$tmpTools->templateurl();' and '/image/but_static.png' with the right location where you saved the button and with the name you gave the file when saving. The most popular position to inser this code into is by the existing buttons for CSS and XHTML Validation if you already have them (take a look at the bottom of this page to see what I am speaking about) but you may put it anywhere else if you like. If you do nos have such buttons then find the footer and insert it under '<jdoc:include type="modules" name="syndicate" />'. This is the main reason that we do not do this automatically within the plugin; that you may put it whatever you like and should we do it automatically we could break your template so must do it by hand.
<a href="http://www.doymer.com/static" target="_blank" title="<?php echo JText::_("We Serve
Static Content");?>" style="text-decoration: none;" alt="<?php echo JText::_("We Serve Static Content");?>" />
<img src="/templateurl(); ?>/images/but-static.png" border="none" alt="<?php echo JText::_("We
Serve Static Content");?>" />
You may edit your template directly from the hard disk if you have access or you may edit it from the template option in the admin control panel of Joomla!. Whe finished update your page and check that everything works as it should.