Html tidy

I have html tidy installed and enabled via php 5.1.x. I tested the install by:

<?php
    $tidy = tidy_parse_string("<B>Hello</I> How are <U> you?</B>");
    tidy_clean_repair($tidy);
    echo $tidy;
?>

And am able to get the html fixed in the results. My php install doesn't have any values for open_basedir so I'm not sure if that is the problem.

I'm also not sure what to set the "Path to HTMLTidy executable" - the default value of /usr/bin/tidy seems to throw errors:

* warning: exec() has been disabled for security reasons in /nfs/disk/data/www/virtual/webdev.ous.edu/cws/modules/import_html/coders_php_library/install-htmltidy.inc on line 87.
* HTMLTidy executable is not available. Found 'tidy' binary, but it didn't run right. /usr/bin/tidy -v failed to respond correctly

Any ideas?

Comments

Comment #1

harriska2 CreditAttribution: harriska2 commented 21 February 2007 at 19:48

Status:

Active

» Closed (fixed)

Never mind, this particular site does not allow executables. We will try to use it from a command line mode. Or try to setup one site for this.

Another site had the open_basedir restriction. What a pain. I ended up putting the tidy compiled file under one of my allowable directories and pointing import_html at it. I then had to put all files under the one directory without subdirectories (how nice). But it did work like a charm.

Comment #2

shiva7663 CreditAttribution: shiva7663 commented 4 October 2007 at 19:00

Am I correct in assuming that if you can convince your hosting admin to install the PHP Tidy extension, the module won't use exec() at all, thus successfully bypassing the issue?

Comment #3

dman CreditAttribution: dman commented 5 October 2007 at 01:49

Um, yes. The php5 tidy extension is used by choice, the commandline version is a fallback.
If you can turn on the extension in your php.ini, it SHOULD be detected and used.

... because different server setups may or may not support different things. I cannot predict all possible configurations, but so far I think I've covered about 80% of cases. Not tried open_basedir problems, but that should be avoidable if you upload your source tree inside your files dir.
My use-cases are to build on a local test box (where I have control) before mirroring the result up to a commercial host.

Comment #4

shiva7663 CreditAttribution: shiva7663 commented 5 October 2007 at 02:50

I'm trying to use the PHP4 Tidy extension, and it's still falling back to try to use a Tidy executable (which fails because exec() is disallowed). Does this module only support the PHP5 Tidy extension?

Comment #5

dman CreditAttribution: dman commented 5 October 2007 at 03:18

Status:

Closed (fixed)

» Postponed (maintainer needs more info)

I don't recall seeing a working version of a tidy extension in the official binary distributions of PHP4 I tried (Win32 & Ubuntu, Debian).
However, if you have got a compiled version, there's a chance that it used a different syntax which I've not been able to read about. ... Oh yeah, there was a version partially distributed under PECL... I never got that to work on my machine...

In tidy_functions I test

  if ( extension_loaded('tidy' ) && function_exists('tidy') ) {
    debug('Using tidy Extension', 3);

... If that is failing ... then the fallback is tried.

Looking at http://nz.php.net/tidy I think that means the php4 tidy was function based (Although I can't see the specific docs) where the php5 is OO.
The invocation may be just as different as the XML rewrite between php4-5. Bloody boring. Totally different code could be needed. I'm not very interested in continuing to support deprecated PHP4, but you may find a quick work-around.

Can you confirm extension_loaded('tidy' ) and that new tidy works for you?

Comment #6

shiva7663 CreditAttribution: shiva7663 commented 5 October 2007 at 05:02

Yep, looks like tidy for php4 is significantly different than for php5. Here's my test code:

<?php

ob_start();

echo '<pre>';
print_r(get_loaded_extensions());
print_r(get_extension_funcs('tidy'));
echo '</pre>';

$out1 = ob_get_contents();

ob_end_clean();

$html = '<HTML><HEAD></HEAD><BODY>' . $out1 . '</BODY></HTML>';

$config = array('indent'=> TRUE,
                'output-xhtml' => TRUE,
                'wrap' => 80);

tidy_set_encoding('UTF8');

foreach ($config as $key => $value) {
   tidy_setopt($key,$value);
}

tidy_parse_string($html);
tidy_clean_repair();
echo tidy_get_output();

?>

which gave me usable xhtml:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<pre>
Array
(
    [0] =&gt; standard
    [1] =&gt; openssl
    [2] =&gt; apache
    [3] =&gt; bz2
    [4] =&gt; ctype
    [5] =&gt; curl
    [6] =&gt; ftp
    [7] =&gt; gd
    [8] =&gt; mcrypt
    [9] =&gt; mhash
    [10] =&gt; mysql
    [11] =&gt; overload
    [12] =&gt; pcre
    [13] =&gt; pdf
    [14] =&gt; posix
    [15] =&gt; session
    [16] =&gt; tokenizer
    [17] =&gt; xml
    [18] =&gt; xslt
    [19] =&gt; zlib
    [20] =&gt; tidy
)
Array
(
    [0] =&gt; tidy_setopt
    [1] =&gt; tidy_getopt
    [2] =&gt; tidy_parse_string
    [3] =&gt; tidy_parse_file
    [4] =&gt; tidy_get_output
    [5] =&gt; tidy_get_error_buffer
    [6] =&gt; tidy_clean_repair
    [7] =&gt; tidy_repair_string
    [8] =&gt; tidy_repair_file
    [9] =&gt; tidy_diagnose
    [10] =&gt; tidy_get_release
    [11] =&gt; tidy_get_config
    [12] =&gt; tidy_get_status
    [13] =&gt; tidy_get_html_ver
    [14] =&gt; tidy_is_xhtml
    [15] =&gt; tidy_is_xml
    [16] =&gt; tidy_error_count
    [17] =&gt; tidy_warning_count
    [18] =&gt; tidy_access_count
    [19] =&gt; tidy_config_count
    [20] =&gt; tidy_load_config
    [21] =&gt; tidy_load_config_enc
    [22] =&gt; tidy_set_encoding
    [23] =&gt; tidy_save_config
)

</pre>
</body>
</html>

So I suppose this means that I'm tough out of luck with this module until my ISP is forced to upgrade to PHP5 sometime in 2008 when official support runs dry (not sure they'll do it even then, I just don't know). Maybe by then I'll be experienced enough to backfill php4 tidy support myself. heh.

Comment #7

dman CreditAttribution: dman commented 5 October 2007 at 05:23

Good debugging!

Well, the meat of the functions needed are all in the first half of tidy-functions.inc:xml_tidy_string() func, and you can see it looks almost identical. Shouldn't be too hard at all to test for a version and try your own way there.

Or if you are more comfortable, you can hack up a way to run tidy some other way on all your files before attempting the import. For paranoia reasons, and also so that we can import ANY XML dialect (like RDF or RecipeML) import_html only tries to run tidy if XML parsing fails at the first attempt. If you can feed it pure, already-valid code from source, tidy is never invoked.

The code is a bit redundant (it runs the parser in a try-catch block) and then tidies and parses again - but it's done that way so you can skip the tidy dependancy altogether ... If you have good input.

Just make sure that it's output-xml not html and ... well, see the configs I use.

    $config = array(
       'indent'           => true,
       'output-xml'       => true,
       'numeric-entities' => true,
       'add-xml-decl'     => false,
       'doctype'          => 'omit',
       'char-encoding'    => 'utf8',
       'wrap'             => 200,
       'repeated-attributes' => 'keep-last',
    );