Hi,
I really like the import_html module, except:
On my shared server (MediaTemple gridserver) there is some sort of file at /usr/bin/tidy, but it is only 22KB and clearly does not work like htmltidy.... so, the module happily finds that file by name and insists that it is htmltidy, when in fact it is not, and then the module does not allow it's erroneous conclusion to be over-ridden via any of the module settings.
To solve the problem, I went to the database and entered the proper path directly into the "htmltidy_apppath" variable.
It appears that the import_html module should utilize some better scheme of testing before concluding that it has found a valid copy of htmltidy, and/or there should be a convenient means to specify the proper path.
Comments
Comment #1
dman commentedSounds like a messed up set-up, but yep, there's no harm in testing a little better.
I've set it to only save the tidy_path setting on test success, not just on file_exists as it was before.
This will then display the UI for entering your own path - which exists, but may not have been displayed as it already thought things were good.
note - if the bogus file you found at /usr/bin/tidy is actually executable and runs OK, I can't tell the difference, so the run-test will succeed.
However, I've exposed the config (which was always there, just hidden) so you can manually over-ride whichever path you want.
Try the latest CVS to see.
Comment #2
dman commentedSounds like a messed up set-up, but yep, there's no harm in testing a little better.
I've set it to only save the tidy_path setting on test success, not just on file_exists as it was before.
This will then display the UI for entering your own path - which exists, but may not have been displayed as it already thought things were good.
note - if the bogus file you found at /usr/bin/tidy is actually executable and runs OK, I can't tell the difference, so the run-test will succeed.
However, I've exposed the config (which was always there, just hidden) so you can manually over-ride whichever path you want.
Try the latest CVS to see.
Comment #3
dman commentedSounds like a messed up set-up, but yep, there's no harm in testing a little better.
I've set it to only save the tidy_path setting on test success, not just on file_exists as it was before.
This will then display the UI for entering your own path - which exists, but may not have been displayed as it already thought things were good.
note - if the bogus file you found at /usr/bin/tidy is actually executable and runs OK, I can't tell the difference, so the run-test will succeed.
However, I've exposed the config (which was always there, just hidden) so you can manually over-ride whichever path you want.
Try the latest CVS to see.
Comment #4
dman commentedBlasted Drupal.org stopped responding for 15 minutes - hence triple-post.
Comment #5
rshelq commentedAfter further testing, it appears that the /usr/bin/tidy on my Debian system is indeed working ok, but apparently there is some sort of path problem that causes tidy to fail.
So far, I'm only using the Demo mode, and it always fails when trying to use tidy located at /usr/bin/tidy, but the Demo does work fine when using another version of tidy that I have added at import_html/bin/tidy.
In the failure notice, the path is simply shown as "files/imported/mv2/I/I_I_0.htm". Apparently tidy at /usr/bin/tidy can't access that file.
Comment #6
dman commentedThat's not quite enough information to go on.
Permissions? user_base_dir?
Have you checked that that file does exist? It gets deleted immediatly after parsing in normal mode, but I think if we turn on debug, it leaves it for analysis.
In one historical version anyway.
Have you tried putting that actual file through tidy yourself? There are potentially a few bad HTML sources that even tidy can't fix, but I have only found a few of them.
The errors SHOULD be displayed, but not everything can be caught.
Comment #7
dman commented