reverendspam
There is a reason that Tidy is not implemented by most ISPs. It breaks certain functions of different php programs and is more trouble than it is worth.
Tidy does not take the place of poorly written code. If you want compliant code then write it to be compliant or ask the developers (nicely) to make sure their code is WWW3 compliant.
For those using jomsocial,I know for a fact, this plugin will break your registration process.
Your user , upon registering, will get the error PHPMAILER_EXECUTE/usr/sbin/sendmail
which means your user will not get a notification email and they will not be able to log into the new account they just created.
I strongly advise not using this plugin as it may break more than it fixes. History repeats itself and this is the only reason I am commenting here.
I'm of the philosophical school of thought, "If it ain't broke, don't fix it." If your site works, don't fix it. Compliance is only a goal for programmers and web browser creators. The end user should not have toput a band aid on the situation. Compliance is not set in stone and has no control over MS who currently has the market on web browser usage - like it or not.
This is not a slam on the developer - the plugin is written well.
Hi reverendspam,
I understand to certain degree your point of view but I don't completely share it, let me explain mine.
Tidy is the easy "plug-n-go" option of the plugin but I agree that Tidy can cause some problems, in fact the use of it is disabled by default in CleanHTML and I don't personally use it with my Websites, but I included the option because other people might find it useful (with simpler sites, for example not using JomSocial).
The strongest part of this plugin is it's manual cleanup and custom replacements (and that is what I recommend to use instead of Tidy), you can write your own string replacements using straight PHP, regular expressions, etc.
In fact custom replacements can be used to whatever you need, not just to accomplish standards compliance but any other thing you may need to modify after the page is generated by Joomla but before it is sent to the visitor's browser.
Compliance is generally a goal of programmers and web browser creators as you said but this is not entirely true, in fact I wrote this plugin because a client of mine requested specifically an XHTML 1.0 Compliant Joomla Website and I was going crazy trying to accomplish that, there are some people out there (not necessarily programmers) that also care about this (usually technology related businesses).
I installed this plugin (didn't use Tidy), enabled the manual cleanups, added some custom rules with PHP and voila! got what I needed :)
This plugin is not magical in the sense that it probably won't make your page valid XHTML just by installing it (unless you enable Tidy), but it will get you very close so you can do the rest by adding manual string replacements in there.
If you're a developer and face a situation like the one I just mentioned or you just care a lot about Web standards you know now you have now an option.
This plugin is mainly intended for Web developers because you might need to know about Web standards and some basic PHP, if you don't I would say that this plugin may not be the right one for you.
This is a nice little component that should be a part of the core.
I created a static page with a link to reset password and a link to or have your username emailed to you if you forgot it.
I then use this plugin to redirect to that static page.
The install went simply as do most Joomla components. The initial indexing of 100 pdf files proved to be a resource hog as it send warning bells and whistles to my isp. PDF Indexer used over 20% of cpu resources.
My account was immediatley shut down by a linux script and I had to call my ISP to have my account reinstated. They told me that it was most likely caused by poorly written code and it is rare they have many problems with Joomla (which they advertise).
After the initial indexing the program will skip the previously indexed files and just index new files added. I would suggest that you index maybe 10 files at a time.
I informed the author and I think he may be looking into this. It would probably be easy to add some sort of timer when indexing that allows 5 files to be indexed every minute or so. If you have your own server this will not be an issue, but for those of us that are on shared systems we will get hammered by our isp's. Like I said this should be a simple fix adding a couple of lines of code.
The second issue I have is that most of my pdf files were created by Adobe acrobat 7. This caused pdf indexer to not work properly and gave errors on every file created with acrobat 7 (uses AES encryption - version 1.6 pdf files).
The reason behind this is because pdf indexer uses the program xpdf for its pdf to text conversion and then dumps the converted text into your database.
It is a widely known issue that xpdf is not capable of reading version 1.6 pdf files at this point in time. Therefore there were errors with every pdf ver 1.6 file. It works fine with ver 1.5 and below.
If I would have known all this up front I would have not purchased the program in its current state.
Once you get past these problems on the backend, the frontend appears to work well in that the pdf's that did index showed up properly in a search.
I feel that the author is not very responsive to these issues for charging for a product that only half works.
This can be a great product, but it relies on an outdated engine (xpdf). The author should let folks know this up front before they purchase.
"PDF Indexer used over 20% of cpu resources."
This is the first report of this I have seen.
"It is a widely known issue that xpdf is not capable of reading version 1.6 pdf files"
It does read and index the files. There is just a warning at the beginning of the index.
I responded to this user within 1 hour of his complaint and then never heard from him again.