Thankyou for this great module. This does exactly what I wanted. I succesfully imported albeit very 'simple' HTML pages that are created from a genealogy GEDCOM with a perl script then imported into Drupal using Import HTML. Used wgHTML module in the past but this does not seem to be being maintained.

Maybe I'm missing something but I noted the following behaviour:

Drupal 5.0 installed

Access control:
Could only run this as admin/user1 and not fredblogs/user3 (member of administrator role) otherwise I get access denied on the link http://example.com/cms/admin/import_html/import_site

admin/user1 admin and fredblogs/user3 (with admin rights): admin menu options differ, admin/user1 has all options fred blogs/user3 has a subset.

Import HTML settings / Replication options:

'Imported nodes are published' - I checked the box but the imported node is shown as not published.

'User to create nodes as:' - I changed this from 'admin' to 'fredblogs' but this setting does not appear to get saved (defaults back to admin on saving the settings), though when I check the imported node author it is shown as 'fredblogs'

Comments

dman’s picture

dman commented

Requirement to be admin is a known issue that's maybe going to be patched next time.

The 'create user as' option being un-sticky is very probably a side-effect of the very recent and untested port to 5.0 forms. I'll note it as something to check.

Possibly something similar for the 'published' flag. That's a bit more serious, (for the uses I've been putting it to) so I'll look into it.

Thanks for the feedback.

Hetta’s picture

Hetta commented

On my clean install this 5.x.1.x-dev version works like this:
1) if a file (or a set of files) is marked [x] published it gets published.
2) if a file (or a set of files) is marked [x] menus it gets into the menus, if it's not, it doesn't.
3) the "publish as" user is the admin, nevermind what is entered into the settings and the "More settings" fields (beneath the "Next" button).
4) Changing the xsl (or xslt) file name in the settings is currently completely undoable: if the name is changed there are errors: "can't find the file" plus "can't parse the file" (or similar), and that error won't go away. I don't know if the given file would still work, though - I didn't think to test that, opting for a reinstall instead.
5) you say in the help file that importing as something besides "page" is fixed (and I got that to work in the 4.7 version), but I can't find any way at all to do that in this version.
6) html2drupal.xslt is marked as dead in the CVS tree - should it be?

Thanks!

Hetta’s picture

Hetta commented

Oh, and I'm on drupal 5.1.

dman’s picture

dman commented

I reviewed also last night and found no trouble with setting them published.

I found some trouble with the menus, which I patched.

I encountered the non-sticky, but still working, user-change problem. It was, as suspected

    '#default_value' => $user->name,

where it should have been

    '#default_value' => variable_get('import_html_import_user',$user->name),

You are right that changing the XSL was un-do-able :( . The check used to be before the form was submitted (so you'd see the problem even if you were not making any changes) I've now moved it into the usual form_submit phase.

Thanks! Looks like the content-type selector missed out on the trip through the upgrade.
It was added to MAIN after the October branch that larrychu based the upgrade on.
I've put it back - and found and squashed a segfault problem in the process.

The template to use is html2simplehtml.xsl , and has been for a while. the html2drupal was compatable with the old 4.6 import/export module, but I don't use that XML schema anymore. Internally it converts from raw html to semantic XHTML and absorbs that. No made-up xml dialect any more.

Thanks heaps for those tests! I'll commit the fixes now ... then see how to make them roll...

jupiterchild’s picture

jupiterchild commented

I installed the latest development version and the changes you made seem to have fixed the issues I was experiencing, except for the imports not being published. I spent a few hours this evening trying to figure this issue. I tried lots of different settings removing modules etc. but to no avail. I tried changing the content type to 'story' and publishing to the 'front page', still no joy. I also installed 'Import HTML' on a test site with all contributed modules disabled but still the imported pages refuse to publish.

These are my preferred settings, though I did test other combinations:

All page files found under
../test
will be re-created underneath
http://www.example.com/cms/imported/ as page type nodes.
* Links found within the sources will be rewritten to try and allow
for the new paths
* Non-page files imported will be saved beneath
http://www.example.com.com/cms//home/xxxxxx/drupal/drp3/imported/
* Default document index.html will be used to represent folders.
* New pages will not be added to the menu.
* Imported pages will will be published by default and will not be
promoted to the front page.

It's no big deal for my site since I can easily publish the pages through admin/content and of course I could still be missing something, so I guess I will just have to wait to see if any other users report a problem.

Just one other thing I noticed and I always hate having to tell developers this, a little typo on the line below:

* Imported pages will will be published by default and will not be

Once again thanks for the terrific module and the quick support, much appreciated.

dman’s picture

dman commented
Status: Active » Closed (fixed)

Typo finally fixed a year later. :) Not sure what the status of 'published' problem ended at, but it's not been replicated recently.