jFinalizer joomla plugin
documentation, how-to and support
- Installation Workflow
- Configuration Tips
- Setup Guide: HTML compression
- Setup Guide: CSS / JS aggregation
- Setup Guide: use both together
- known Issues
- Tips, Tricks, Troubleshooting
- A primer about compression efficiency
- change log
- comments & bug report
Please select your version. Note that jFinalizer 2 requires joomla 1.6 or later.
|current release||2.0.1 BETA
please bugreport - beta version.
no further development planned for 1.x
older PHP5 versions might work
Never install on PHP4!
|major changes||- CSS exclusion list
- complies PHP5.3 strict standards
- some option changes, divided into basic / advanced
- plugin order change if system.cache plugin is used
|supports Joomla 1.6 Update System||yes||no|
|tested against||joomla 1.6.5
Important Change on V2: jFinalizer 2.x uses a different plugin order because of joomla 1.6. As before, jFinalizer should be the last plugin in your chain. But if you use joomla's SYSTEM - CACHE plugin, this must be last even after jFinalizer.
Install: right click, copy URL and paste into joomla for installing by URL. Otherwise just download the plugin and upload manually. See changelog. License: GPL, no registration required, free of charge. Component developers please see the tech notes.
Warning: Do not install jFinalizer on PHP 4!
Use jFinalizer if you want to reduce HTTP requests to site, reduce traffic, speed up page loading or decrease HTML page size if you have big templates. On big templates, you can gain 10+ YSlow points, sometimes more than 20. There are many other libraries which do similar things, but we built and run jFinalizer because most of the templates we used would not work with other plugins.
- compress & merge CSS files
- compress & merge JS files
- compact HTML output
- gZip file ouput
- no database access
Do not use jFinalizer if you want the last bit of compression. Its designed for runtime performance, not for super-high compression.
Do not use jFinalizer if you have components, extensions or templates which generate dynamic CSS on the fly (no - you usually don't have that, even on complex templates).
Do not expect jFinalizer to work out of the box. Default settings are compatible for most sites, but tuning HTML output is a tricky task and highly depends on your template, CSS, Java Script, components, plugins and modules. Give yourself 10 minutes to get this plugin configured properly.
Simply right click and view the source of this page or view the source code of our corporate main site www.farbfinal.de to see what jFinalizer does. Actually, both use the same joomla! installation but different templates.
The idea of jFinalizer is to replace tons of JS and CSS files with a single CSS and JS file. This is done by processing the final joomla output HTML. Additionally, you can compact & compress a few things and make your HTML look more compact.
jFinalizer uses another approach than most libraries we've found: It does not do anything to CSS, HTML and JS code except for stripping whitespaces and stuff which is not needed. The plugin merges all CSS and JS files used in a page into a single file, preventing the loading order of the html source. Note that only CSS and JS files within the region are processed. We've found that processing body CSS and JS usually harms on complex templates.
jFinalizer is designed for live performance. This requires a bit more tuning on the developer side, but reduces runtime CPU usage at runtime a lot. jFinalizer has its name not only because our company is called farbfinal, but also because its usually the last plugin in the system chain and finalizes your output. Your goal is to develop your site, then turn on jFinalizer and see what happens. If your code is clean, you're on the way to go.
- CSS and JS files outside the <head></head> section are ignored
- files containing a questionmark after the extension are ignored (my.css?v=10) because we assume they are danamic
- inline CSS and JS is ignored
- some features are not available on all platforms and server configurations (see Options)
- HTML compression does no fixing like tidy
In Production mode, the plugin performs quite well and does not consume a lot of CPU. For performance analysis and before / after comparison, please use external tools such as YSlow (FF Plugin). Since jFinalizer is a system plugin we want to keep it slim, there are only a very few analyis options build into plugin (see configuration).
1. install the plugin and set it to plugin order "last". For joomla 1.6 only: If you use the SYSTEM.CACHE plugin, put this even after jFinalizer.
2. set plugin option Site Mode to development (install default - your site becomes slow)
3. check your fontend pages for design breaks
4. tune jFinalizer options
5. reload site, make sure browser cache is cleared
6. repeat (4) and (5) until everthing works
7. turn Site mode into production
PLUGIN ORDERING: Make sure your plugin ordering chain is right. This setting must be different for different versions of joomla.
Joomla1.5+: jFinalizer absolutely last
Joomla1.6+: jFinalizer absolutely last, except you use joomlas system.cache plugin.
Tip: Whenever you change a CSS or JS file later or install new joomla! components / plugins, turn jFinalizer into Development Site Mode and check life site again.
Tip: While configuring, do one thing at a time. If you want HTML compression, start there and disable all CSS / JS processing. See HTML setup guide
Don't give up tuning to fast. Allow yourself 10 minutes to get it working properly. If there is no combination to get your template working, this plugin is probably not for you. Try a different approach like CssJsCompress or JACompress.
When installing a jFinalizer upgrade, simply install it. The plugin does not need to be uninstalled before.
If your site does not work properly, your goal is to turn jFinalizer off, see your HTML source code, then turn the plugin on, reload, see your source code again and compare. First steps for setup could include this procedure:
- Turn jFinalizer into Site Mode Development
- disable all options (no HTML processing, no JS processing, no CSS processing, all compacting to off, no gZip). If your site still breaks, something is wrong and this plugin is not for you. Otherwise, continue turning on step by step and reload after every step. Try this order:
- Turn on CSS processing
- Turn on CSS compacting (now your site gets slower)
- Turn on HTML processing, try DeTab mode (default) first
- if you have a working site now with some combination of the modes above, continue to configure gZipping, removing HTML comments etc. if you wish.
Tip: Any Compacting can break layout. If your server supports runtime gZip compression, thats probably not a big deal and you can turn it off
Tip: if your site uses many joomla components, make sure to also check the pages where they appear! For example, you could get a perfect layout and performance with HTML compression set to ultra, but some poorly coded component might break it or not work as expected.
Tip: If HTML compression is what you want most, work the other way around. Disable CSS and JS processing first, enable HTML processing and be sure to try all available modes! If you have the system.cache plugin enabled, disable it while tuning. Try to start with DeTab mode (default). Read the HTML Setup Guide.
To see an example, right click and look at the source code of this page. Farbfinal.de is run against jFinalizer with HTML processing mode set to fast using moderate compression and check contitional exceptions, JS on and optimize, CSS on and optimize, remove comments and deliver using gzip htaccess.
HTML processing is the most tricky part. Stick on this workflow to get it working. Be sure your browser reloads properly and dont try to get CSS / JS aggregation to work before HTML processing if you want both.
- install jFinalizer
- optional: temporary disable the system.cache plugin if you use it.
- in jFinalizer, disable CSS processing, JS processing, gZip delivery, HTML comment removal, generator Tag removal
- set process HTML to fast - builtin
- try all available compression levels, a good start is DeTab
- save the settings, reload your front end, see what happens
- if design and / or functionality breaks, repeat steps 5-6
- once your design and functionality works, you may try to enable HTML comment removal and generator tag removal. Be sure to check front end again!
- optional: when you finished all jFinalizer configuration, enable system.cache again if you used it
If you dont want HTML output processing, try this workflow to setup CSS / JS processing properly. This may help to to get your site working a bit faster.
- install jFinalizer
- disable the system.cache plugin if you use it
- set jFinalizer to site mode: development
- in jFinalizer, disable HTML processing, CSS processing, JS processing, gZip delivery, HTML comment removal, generator Tag removal
- start with enabling CSS / JS processing, on switch at a time
- save the settings, reload your front end, see what happens
- if design and / or functionality breaks, repeat steps 5-6
- when everything works as expected, remember so set jFinalizer site mode into production
- optional: when you finished all jFinalizer configuration, enable system.cache again if you used it
See instructions above. Be sure to first get HTML compression working properly at first, then start CSS / JS file processing - not the other way arround!
the default configuration should work for most installations:
Your most important switch while tuning and developing. Controls how jFinalizer handles its internal cache. Yes, you want cache! The cache system on jFinalizer operates independent of all joomla! cache settings, because its always content independent. Caching in jFinalizer means that JS and CSS files are stored to disk and not re-processed on every page load. HTML output is never cached by jFinalizer. Using jFinalizer without cache does not make sense because you would decrease HTTP requests but at the same time increase execution.
While developing design (CSS) or functionality (JS) you want to turn Site mode into development. When your site is up, fixed, steady and running - go for production.
Note: development mode reduces performance big time - your site will slow down drastically.
- production:live site mode, caching enabled
- development: cache disabled, files are always re-created, cache cleared on every page load.
removed in version 1.1.0. Also, Tidy support is not available in jFinalizer 1.1.0+
Sets the compression level of HTML output.
Depending on how clean your template is, you can reach different compression levels. Compression levels also affect CPU usage on the server side a bit. Please note that the most efficient and fastest mode is ultra, but unless your template is super-clean, ultra mode will probably break your layouts.
All modes try to remove as many white spaces as possible. Ultra also removes all line breaks. The difference in the operating modes is how deep the plugin digs and how much whitespace is removed. Some modes do additional checking to prevent design breaks. Please try and see which option works best for your template.
The different options are available because the idea if jFinalizer is to perform as fast as possible and do as few checks as possible at runtime.
- Off: No HTML processing
- DeTab:remove Tabs and leading white spaces. Safest, most efficient and fastest algorithm
- other options: vary - try them yourself. They might break layout.
Tip: Published starting at jFinalizer 1.1.0, DeTab seems to be most compatible. Its also the current installation default setting. We did a lot of testing and performance comparison. While being much more compatible and 2x faster than our best algorithm so far, Safe mode C+, HTML size increases typically between 0.5-1% only when using DeTab compared to Safe Mode C+. Also, source code looks very clean now. So we strongly recommend DeTab now.
Note: Starting from some of the next releases, only compression modes DeTab, Safe Mode C+ and Ultra will be available. Others will be removed an depreciated!
Keep or remove HTML comments. It takes a bit CPU but usually is a good thing if you want to clean your output. Please note that multiline comments are always kept!
- remove: remove HTML comments
- keep: keep HTML comments
Never touch <pre> tags. Don't remove linebreaks, whitespaces etc. This option is available on jFinalizer 1.0.11+. Useful for plugins like CodeCitation. If you know your site does not have any <pre> tags, turn it off for a tiny bit of extra performance.
- Yes: support checking of <pre> tags
- No: skip <pre> tag checking
Keep or remove the joomla! generator meta tag. Can help a bit to not expose joomla. Note that there are other ways to do that but they require joomla ource code editing.
- remove: remove generator meta tag
- keep: keep generator meta tag
remove whitespaces and other unused stuff from JS files. Usually saves a couple bytes. In some cases, compacting JS can break JavaSvript functionality. If thats the case, try disabling it.
- Yes: compact JS
- No: leave JS untouched and simply merge the files into one
resolve jQuery conflicting Ajax libraries - added by feature request, v1.1.4+
- Yes: include jQuery.NoConflict() patch
Never process those files. Type any phrase in there. Case unsensitive.
You can manually enter a comma-separated list here to exclude specific files. These files will always be skipped. For example, the default setting tini_mce.js ensures that the joomla default TinyMCE editor will still work in the front end when users edit content.
UPDATE: jFinalizer 1.x can only exclude JS files. jFinalizer 2.x can exclude both JS and CSS.
- default: tiny_mce.js,xajax.js
same thing as compact JS but for CSS
Check it the template contains conditional <!--if... --> CSS includes for client browsers. If it does, they are ignored. The option is available because if YOU KNOW your template does not have any conditional includes, you can turn this option off and save some extra performance.
- Yes:check for conditional includes (recommended)
- No: bypass check
compress cached JS and CSS files using gZip.
gZipping JS & CSS files can drastically reduce file size and download time. When run in .htaccess delivery mode, additional PHP calls are bypassed and runtime compression by the delivery server (eg. apache) is skipped. This can reduce overall load and File I/O on your server. Please note that .htaccess mode is not available on all platforms. If you run a dedicated server, this option is for you to tune the last bit. The modes explained for experts:
PHP delivery: the client browser calls a PHP file which delivers the JS / CSS file dynamically and adds necessary css headers. The files are already compressed, but PHP needs to be opened and a fopen() function is involved.
.htaccess delivery: a .htaccess file is placed into the delivery folder (usually /cache/assets). The web server checks if gZipped content is accepted by the client and rewrites the request file name to deliver the gzipped version. Fast, no additional PHP calls. On apache, mod_rewrite must be enabled and allow_overrides must be properly set for the cache path. If Apache is set to compress .js and / or .css files by default on the fly using DEFLATE, this will be bypassed for those files saving CPU time.
To customize the content of the .htaccess file depending on your server configuration, copy the file /plugins/jfinalizer/htaccess.default.php to htaccess.custom.php and edit this file. This way, your changes remain after you upgrade jFinalizer. Note: .htaccess configuratio requires jFinalizer 1.0.4+
Please note that apache knowledge is required when editing the .htaccess file contents. The goal of the .htaccess file is to check if the client accepts compressed data, and if thats the case redirect the request to the gzipped version of CSS / JS files.
- off: no compression
- gzip PHP delivery: compress & deliver files using PHP
- gzip .htaccess delivery: compress & deliver files using .htaccess rewrite (recommended)
As CSS and JS files dont change once you finished designing, cache lifetime is usually set to 0 meaning the files never expire. However, you have the option to enter an amount of seconds to force rebuilding the merged files after that period. Do not confuse "expired" here with http expiring / client cache lifetime: HTTP send Headers are not touched by jFinalizer.
- 0: never expire (recommended)
- (number): lifetime for merged files in seconds
Append some debug info comments or show performance data
Debug mode help you to see what jFinalizer does and how it performs. In html comments mode, a html comment containing the name of the removed JS / CSS files is placed into placed into output HTML source code. This can be useful if you want to see what files were merged.
In full and performance mode, jFinalizer displays performance data such as total runtime of the plugin, number of merged files an HTML byte savings on top of your site. Full & performance breaks design and cookies. So don't use it on a live site - or if you do, turn it off quickly again. While tuning jFinalizer compression settings, don't run full and performance since you can't see compression design breaks.
- off: no debug
- html comments: write file information into output HTML as comments
- full and performance: html comments + display runtime information - improved in 1.1.0
where to place output file tags in HTML.
If you want to do so, call the loading event at the appropriate place within your template and then switch to manual . Usually this is the section which outputs head data. It does not matter if other CSS or JS files are loaded after manual placement. The parsing and collecting always comes later.
PHP Placement code CSS: $mainframe->triggerEvent('getCompressedCSS');
PHP Placement code JS: $mainframe->triggerEvent('getCompressedJS');
($mainframe refers to the joomla mainframe object).
- auto: auto tag placement
- manual: manual tag placement
delivery output path for CSS and JS files in client HTML
Now thats tricky. By changing the delivery path, you can tell the client to load the merged JS and CSS files from another source path. Its great for hiding the default joomla /cache/xxx directory.
Cached files are always stored physically on disk into the joomla cache directory, subfolder /assets. So, usually thats /cache/assets. You can't change that because thats the only way to clean jFinalizer cache using the joomla builtin cache manager.
Re-routing the delivery path works by placing a symlink to /cache/assets. You need shell access. Login to your server and create a softlink. For example on linux, if you want you delivery path to be example.com/inc, you would create the symlink using
bash># ln -s /my/absjoomlarootpath/cache/assets /my/absjoomlarootpath/inc
and then insert inc/ into the delivery Path field. Note that Apache might check symlink permissions. They need to be set correctly.
- (empty): dont re-route include path
- inc/ : re-route include path to example.com/inc
Let Finalizer try to include asset files that are not stored on the actual server. This option is experimental - we need feedback on this!
The PHP directive allow_url_fopen must be enabled. Also, please note that any files containing a "?" or other suffixes, like style.css.php, are considered dynamic and are always skipped.
- (yes): try to include remote CSS files
- no : don't
Tell jFinalizer if joomla is installed in a subdirectory.
Unfortunately, joomla might do strange things sometimes when installed in a subdirectory. Although there is a $live_site directive in joomla's configuration.php, this setting might break some 3rd party components. jFinalizer itself is not affected by that issue, but other than most joomla core components it needs to reconstruct url's that are already parsed out. So, to be more compatible, we decided to give that extra switch. Also, it accelerates a bit because we have less string processing to to.
Please not the spelling: if your site is installed into www.example.com/joomlarootdir, you must enter /joomlarootdir - not joomlarootdir/, joomlarootdir, /joomlarootdir/ or example.com/joomlarootdir
- (empty): root instalation
- (/somedir) : joomla's install directory.
may break when using HTML output compression. In general, when optimizing a site, you want to avoid inline JS at all if possible. If you have out-commented inline JS and your site breaks, try to turn off HTML comment removal first. Be sure to then try all available HTML compression levels.
- .htaccess gZip delivery
is a strong feature but usually needs modification to your specific server needs to work properly on your server. While in development mode, the .htaccess file is always recreated so you can check your changes.
- be patient on HTML compression
If you want HTML output compression and it does not work out of the box, disable all other options and try different compression levels. See HTML setup guide. jFinalizer's HTML compression algorithms are not designed to be smart but fast. So they require testing on your specific site. Of course that takes time, but you gain performance as soon as it works.
- Upgrade to the latest version
To not break compatibility with sites already using jFinalizer, we will never change existing HTML compression algorithms once published, but rather add new ones. So you can safely upgrade jFinalizer.
Edit: Wrong. We will remove some algorithms which seem to not work for most users - thanks for the tons of feedback we've got so far!
- valid HTML, please!
Using valid HTML / XHTML in your template makes it easier to figure out problems. If your site contains valid HTML and jFinalizer is setup properly, it will also output valid HTML. Keep in mind that jFinalizer does not do any fixing. Having invalid HTML / XHTML before HTML processing might cause many problems and is never a good idea anyway. So before using jFinalizer, make sure your site validates against W3C
- bug report
Please help us to improve jFinalizer and bug report. We'll try to fix as soon as possible and get back on you. So far, we could get jFinalizer running with all of our self-made and third-party templates without modifying a single line of template code.
- PHP Error: unexpected T_OBJECT_OPERATOR
Your site is probably running PHP4. Don't use jFinalizer!
- PHP Error: Warning: fopen(/some/path/somefile.css) [function.fopen]: failed to open stream:
You run CSS / JS processing mode and your site actually misses a file! Check your error logs and you will probably see a 404. This can happen if a joomla! extension appends a CSS / JS file to HTML output which is physically not existing on your server. jFinalizer won't check for that. It assumes that the files needed to display the page are actually existing.
- jFinalizer is active but seems to not do anything
its possible that jFinalizer conflicts with the joomla build-in system.cache plugin. If you use system.cache, make sure you use jFinalizer Version 1.0.7+
- WAMP compatibility on local windows development servers
There seem to be some issues when trying to run jFinalizer on local Windows development machines. Currently, we do not plan to integrate dedicated WAMP support, since jFinalizer needs to be re-configured on the final live site anyway. Workarround: Design your site, upload it and install jFinalizer on your live server as the very last step of development.
Try upgrading to jFinalizer 1.1.0 which has some windows workarrounds. They are still beta, but please tell us if they help or what's wrong!
- bypass html processing
- process HTML only and use another CSS / JS plugin
If for some reason you cannot get CSS / JS processing working but still want the HTML output compression functionality of jFinalizer, you can safely try other CSS / JS aggregation plugins like CssJsCompress or JaCompress. You will not drop performance: All CSS / JS aggregation functions of jFinalizer are only loaded dynamically into PHP if CSS / JS processing is active and files actually need to be aggregated. Make sure to disable all CSS / JS functionality when using other plugins.
- IMPORTANT: Joomla is installed in a subdirectory like www.example.com/joomla. This can cause asset file not found errors.
Since v1.1.0 we have added dedicated subdir support - unfortunately we had to. One more config setting but at tradeoff for better speed. Read more on how to configure
- No CSS / JS files are processed: make sure the type definition is set (eg type="text/css"). This can be a problem especially with HTML5 since HTML5 is a bit lazy here.
- 2.0.1: HTML5 issues with conditional header definitions. We currently investigate.
- CSS files beginning with @charset can cause invalid CSS - design is not affected
- RokBox does not like HTML comment removal - try jFinalizer 1.1.0 + DeTab Mode
- CodeCitation joomla! plugin requires <pre> tag checking (jFinalizer v. 1.0.11+)
- There seem to be issues with jFinalizer when working in PHP Safe mode on some server setups. We still investigate. If jFinalizer is not working for you and you know your server runs PHP in Safe mode, please drop us a bug report with your system info.
- TinyMCE Fronend editor might break even in DeTab compression mode. v1.1.4+ (alpha) solves that issue due to exclusion. Sorry folks, no other workaround found yet.
When you apply output compression or optimization, either on HTML, JS or CSS, you have 2 things in your mind: You want to reduce server load and you want to speed up your clients page loading.
When we first designed jFinalizer, our goal was to reach maximum compression with minimum server CPU load while being as compatible as possible. To keep the tradeoff between compression ratio and CPU usage as balanced as possible, we have setup a reference page and kicked all algorithms which cause jFinalizer to exceed a total runtime of 5ms. We figured that it does not make sense to build a system plugin which requires Page Caching to keep performant.
Since we got lots of feedback from jFinalizer users while (still) being in beta, we could evaluate many different 3rd party components and their behavior on compression. After lots of comparison, we decided to give the go for our newest DeTab compression algorithm: Compared to all others, it does not completely remove line breaks. At first, we did not like that at all. But after statistics evaluation, we were quite surprised. The total increase of HTML size is only minimal, typically between 0.5-1% compared to other algorithms.
- initial release
- changed some descriptions
- switched internal File I/O to builtin class instead of JFile
1.0.2 - download archive plg-system-jfinalizer-1.0.2.zip
- fixed issue on files with "?" appended to CSS or JS URL
- some bugfixes
1.0.4 - download archive plg-system-jfinalizer-1.0.4.zip
- changed safe mode HTML processing algorithm for more compatibility
- add: another HTML processing mode (now Safe Mode A and Safe Mode B)
- add: option to remove Joomla! generator tag
- add: added support for custom .htaccess file contents
1.0.5 - download archive plg-system-jfinalizer-1.0.5.zip
- add: Simple Mode B html processing mode
- fix: German language file missing Tag
- fix: PHP deprecated Warning on some server setups
- fix: added compatibility for use with system.cache plugin
- add: added yet another HTML compression level (Safe Mode C)
- change: changed install default HTML compression level to Safe Mode C
1.0.8 - download archive plg-system-jfinalizer-1.0.8.zip
1.0.9 - download archive plg-system-jfinalizer-1.0.9.zip
- change: set Tidy Developer mode to UTF-8 / XHTML output
1.0.10 - download archive plg-system-jfinalizer-1.0.10.zip
- add: added Safe Mode C+ HTML compression level, keep more spaces
1.0.11 - download archive plg-system-jfinalizer-1.0.11.zip
- add: added switch
- add: added <pre> tag support
- fix: fixed Warning: get_class() error on certain PHP5.3 installations
1.1.0 - download archive plg-system-jfinalizer-1.1.0.zip
- major code rewrites
- changed CSS optimization engine
- improved overall performance
- fixed some issues with remote asset files
- fixed a jomsocial problem with facebook connect (thanks to the azrul team for providing a jomsocial dev copy)
- fixed a problem with google maps plugin
- added error handling engine
- separated code to include debugger only of in Debug Mode
- improved debugger messages
- added DeTab HTML compression mode (way faster, very effective, very compatible) - this fixed most 3rd party component issues. Please try this mode first!
- removed TIDY support
1.1.1 - download archive plg-system-jfinalizer-1.1.1.zip
- fixed: error handler loader bug (thanks to Douglas Machado)
1.1.2 - download archive plg-system-jfinalizer-1.1.2.zip
- fixed a bug with JomSocial news feeds
- fixed a php undefined notice
1.1.3 - download archive plg-system-jfinalizer-1.1.3.zip - current release
- fixed a setup xml bug for the errorhandler class
1.1.4 - download alpha version plg-system-jfinalizer-1.1.4.zip
- added by feature request: jQuery.NoConflict() support
- added by feature request: custom exclude JS files
- bug fix: tiny MCE exclusion fix, moved to exclude JS files section
1.1.5 - download alpha version plg-system-jfinalizer-1.1.5.zip
- fixed a bug with textarea tags (thanks to Mic)
- joomla 1.6+ support only
- PHP5.3+ rewrite
- Strict Standards compatible
- supports joomla 1.7+
- FIX: exclude css type media="print", bug report from Alex 2011-06-17 17:08
- FIX: corrected a bug in error 200 message handling
- ADD: File skip list now supports both JS and CSS, by feature request (CSS exclusion)
- CHANGE: File Skip list not case sensitive anymore
- CHANGE: Re-arranged backend options (simplify), divided into basic an advanced options
- FIX: language bugs
- CHANGE: Debug window redesigned, validates against W3C
- ADD: Supports 1.6 joomla update system
please note: when upgrading to 1.1.4 from an older version, be sure to hit "apply" in the backend plugin editor once (initialize newly added parameters)
Comments & Bug Reports
When posting a bug report or problem, don't forget to post the jFinalizer version. If you use HTML compression, tell us what Mode you use.