jFinalizer joomla plugin
documentation, how-to and support
Please select your version. Note that jFinalizer 2 requires joomla 1.6 or later.
jFinalizer
current release
2.0.1 BETA please bugreport - beta version.
1.1.5 no further development planned for 1.x
PHP5.3 older PHP5 versions might work
PHP5 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
tested against
joomla 1.6.5 joomla 1.6.6 joomla 1.7.0
joomla 1.5.23
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 . License: GPL, no registration required, free of charge. Component developers please see the .
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.
Key Features:
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
to see what jFinalizer does. Actually, both use the same joomla! installation but different templates.
Description
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.
Even though joomla! is a great CMS, it has a few drawbacks. Joomla's flexibility is awesome, but at the same time it introduces a lot of file I/O on the application server. jFinalizer can help a little to improve that. It does not check for updated CSS or JS files since the developer knows anyway when design is changed. Imagine you have a template with 9 CSS and 7 JavaScript file includes. Makes 16 all together. jFinalizer reduces it to 2 (see limitations). This reduces Server file I/O. Since jFinalizer does not check the modified date of the source files, 14 file system calls are saved.
Limitations
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
Performance
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).
Installation Workflow
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
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.
Configuration Tips
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 JavaScript processing
Turn on JavaScript 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 .
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.
Setup Guide: HTML compression
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
Tip: for bypassing HTML processing for only a specific block of Text or content plugin, wrap it with My bypassed content goes here
in the article editor.
Setup Guide: CSS / JS processing
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
Setup Guide: use both together
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.
Tip: while in designing layout in development mode, disable JavaScript & CSS compacting
production:live site mode, caching enabled
development: cache disabled, files are always re-created, cache cleared on every page load.
process HTML
removed in version 1.1.0. Also, Tidy support is not available in jFinalizer 1.1.0+
HTML Compression
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!
HTML comments
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
Pre Tag Support
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
Generator Tag
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
process JavaScript
Does what it says. Process all JavaScript tags, read the files, merge them into one and cache them. Note that having external url (from another server) javascript within your &head& tag will probably break the script.
All JavaScript files outside the header &head&...&/head& tags are ignored.
Yes: process JavaScript
No: ignore JavaScript tags
compact JavaScript
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.
Performance note: compacting JavaScript files is usually the most time consuming task of jFinalizer. While this is not a problem in production (cache) mode, you might want to turn JS compacting off when in development mode.
Yes: compact JS
No: leave JS untouched and simply merge the files into one
jQuery NoConflict() support
resolve jQuery conflicting Ajax libraries - added by feature request, v1.1.4+
Some Ajax libraries might fight each other. The jQuery library contains a switch which can resolve this issue when used together with other libraries, such as joomla's default MooTools. However, jFinalizer has the option to inclide that switch because sometimes, 3rd Party components already call this JavaScript statement, so it's not needed a second time.
Yes: include jQuery.NoConflict() patch
No : leave JavaScript as is
Skip Files
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
process CSS
same thing as as process JavaScript but for CSS files
compact CSS
same thing as compact JS but for CSS
check conditional Exceptions
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
gZip output
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)
cache lifetime in s
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
Advanced: Place Tags
where to place output file tags in HTML.
By default (auto), the first found tag (CSS / JS) in your source template is replaced by the merged output file. However, you can optimize tag placement by manually placing tags. For example, if you have a minimal template which has not a lot of JavaScript, you could move all JavaScript from the &head& to the bottom of your body. Anyways, manual template editing is necessary.
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
Advanced: Delivery Path
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 /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 /inc
Advanced: Remote File support
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
Advanced: joomla subdirectory
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 /joomlarootdir, you must enter /joomlarootdir - not joomlarootdir/, joomlarootdir, /joomlarootdir/ /joomlarootdir
(empty): root instalation
(/somedir) : joomla's install directory.
tips, tricks, troubleshooting
Inline JavaScript Code 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. As we figured out so far, 90% of broken functionality is caused by inline JavaScript Code when using HTML compression. A good starting point is compression level DeTab, since this fixes a couple JS issues.
.htaccess gZip delivery is a strong feature but usually 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. . 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
bug report Please help us to improve jFinalizer and . 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 Starting from jFinalizer 1.0.11+, you can bypass HTML processing by wrapping anything with my unprocessed content goes in here, for example in the joomla! article editor. This way you can bypass HTML processing for content plugins or specific text blocks. Note that anything can be bypassed, also inline JavaScript and inline CSS, as long as its not within the &head& tag.
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 /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.
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.
known issues
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.
A Primer On Compression Efficiency
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.
Unfortunately, involving compression is always a tradeoff. No matter how efficient the algorithms are - the better the compression, the more CPU usage is needed on the server side. For example, speaking of HTML compression, this involves a lot of additional checking to make sure no inline JavaScript functionality or CSS design breaks.
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.
Now that was good news. Removing line breaks causes heavy problems with inline JavaScript and needs a lot of reconstructing. We have a great balance now: execution time on our reference Page reduced to &2ms and the algorithm did not break any JavaScript yet. So with the help of many jFinalizer users, we think that we have found the perfect tradeoff for jFinalizer and plan to go from beta RC to the first official release.
- initial release 1.0.1 - changed some descriptions - switched internal File I/O to builtin class instead of JFile 1.0.2 - download archive - fixed issue on files with "?" appended to CSS or JS URL 1.0.3 - some bugfixes 1.0.4 - download archive - 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 - add: Simple Mode B html processing mode - fix: German language file missing Tag 1.0.6 - fix: PHP deprecated Warning on some server setups 1.0.7 - 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
- fix: inline JavaScript Bug in Safe Mode C 1.0.9 - download archive
- change: set Tidy Developer mode to UTF-8 / XHTML output 1.0.10 - download archive
- add: added Safe Mode C+ HTML compression level, keep more spaces 1.0.11 - download archive
- add: added
switch - add: added &pre& tag support - fix: fixed Warning: get_class() error on certain PHP5.3 installations
1.1.0 - download archive
- 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
- fixed: error handler loader bug (thanks to Douglas Machado) 1.1.2 - download archive - fixed a bug with JomSocial news feeds - fixed a php undefined notice 1.1.3 - download archive
- current release - fixed a setup xml bug for the errorhandler class 1.1.4 - download alpha version
- 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
- fixed a bug with textarea tags (thanks to Mic)
2.0.0 - joomla 1.6+ support only - PHP5.3+ rewrite - Strict Standards compatible
2.0.1 - supports joomla 1.7+ - FIX: exclude css type media="print", bug report from Alex
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.
Add comment