0
I Use This!
Inactive

News

Analyzed 3 days ago. based on code collected 18 days ago.
Posted about 13 years ago by spflanze
In the files I am importing I have text formatting attributes such as "align" in elements such as or . These are not being imported. This is because in the conversion to a DOMDocument all these attributes are converted to styles that are defined in ... [More] the header. So the DOMDocument object now has two elements. The first is the an original element from my document being imported. The second one is added by the call to the DOMDocument::loadxml() method in import_html's "parse_in_xml_file()" function. None of these two style elements make it past the example xsl file. This is because in the lines: the element is used instead of the element which would transfer the data part of the element containing the style class definitions. Because does not, what is transferred are two empty elements without any style data. But even if this file were tweaked to make the change to the styles will still not be imported because the function "import_html_xhtml_to_node()" imports only and elements from the header. So the import ends up with many class attributes in the body and no element in the header to define them. In my case, it happens that I do not want the element in the documents from the site I am importing because I prefer these styles be defined by the theme. But I do want to keep the element added by DOMDocument::loadxml() because I need attributes such as "align" to import. Right now all text I have center justified in the input document ends up being left justified in the import's output. My case will not be the same for everyone. There is a general need to be able to control what attributes and styles will be imported. [Less]
Posted about 13 years ago by spflanze
In the files I am importing I have text formatting attributes such as "align" in elements such as or . These are not being imported. This is because in the conversion to a DOMDocument all these attributes are converted to styles that are defined in ... [More] the header. So the DOMDocument object now has two elements. The first is the an original element from my document being imported. The second one is added by the call to the DOMDocument::loadxml() method in import_html's "parse_in_xml_file()" function. None of these two style elements make it past the example xsl file. This is because in the lines:    <xsl:for-each select=".//head|.//xhtml:head">      <xsl:for-each select="meta[@name]|xhtml:meta[@name]|rel|xhtml:rel|style|xhtml:style">        <!-- copy most of the head - but NOT metas with http-equiv -->        <xsl:copy><xsl:for-each select="@*"><xsl:copy></xsl:copy></xsl:for-each></xsl:copy>      </xsl:for-each>      <xsl:text>      </xsl:text>    </xsl:for-each> the element is used instead of the element which would transfer the data part of the element containing the style class definitions. Because does not, what is transferred are two empty elements without any style data. But even if this file were tweaked to make the change to the styles will still not be imported because the function "import_html_xhtml_to_node()" imports only and elements from the header. So the import ends up with many class attributes in the body and no element in the header to define them. In my case, it happens that I do not want the element in the documents from the site I am importing because I prefer these styles be defined by the theme. But I do want to keep the element added by DOMDocument::loadxml() because I need attributes such as "align" to import. Right now all text I have center justified in the input document ends up being left justified in the import's output. My case will not be the same for everyone. There is a general need to be able to control what attributes and styles will be imported. [Less]
Posted about 13 years ago by spflanze
In the files I am importing I have text formatting attributes such as "align" in elements such as or . These are not being imported. This is because in the conversion to a DOMDocument all these attributes are converted to styles that are defined in ... [More] the header. So the DOMDocument object now has two elements. The first is the an original element from my document being imported. The second one is added by the call to the DOMDocument::loadxml() method in import_html's "parse_in_xml_file()" function. None of these two style elements make it past the example xsl file. This is because in the lines: the element is used instead of the element which would transfer the data part of the element containing the style class definitions. Because does not, what is transferred are two empty elements without any style data. But even if this file were tweaked to make the change to the styles will still not be imported because the function "import_html_xhtml_to_node()" imports only and elements from the header. So the import ends up with many class attributes in the body and no element in the header to define them. In my case, it happens that I do not want the element in the documents from the site I am importing because I prefer these styles be defined by the theme. But I do want to keep the element added by DOMDocument::loadxml() because I need attributes such as "align" to import. Right now all text I have center justified in the input document ends up being left justified in the import's output. My case will not be the same for everyone. There is a general need to be able to control what attributes and styles will be imported. [Less]
Posted about 13 years ago by mattwmc
I'm doing the Demo and trying to import a page. However, it said: For whatever reason, the request to home/content/xxx/news/imfcbdp.php on /) failed to return a result. You'll have to enable debugging to find out why. So I enabled bugging and saw ... [More] this error: Cannot modify header information - headers already sent by (output started at /home/content/xxx/html/modules/import_html/import_html_ui.inc:1903) in /home/content/xxx/html/includes/common.inc on line 345. No idea what that means, but having a difficult time trying to get this to work. Back to it, I guess! [Less]
Posted over 13 years ago by jefferis
Hi dman, I don't know if you'd like to use this or add it to the instructions, but it might help newbies like me who are trying to import a static site for the first time. Preparing a Static Website for Import into  Drupal A video using the ... [More] Drupal Module "Import_HTML", showing some of the problems and ways to avoid them.  The original site used Dreamweaver templates and legacy code from many updates. This tutorial  deals with web hosts that do not have HTML TIDY installed. In order to get pages to import, you must make them conform to W3 Standards or the pages will fail to import. This process took about a week to import, organize, edit and correct the old site after it was transferred. http://www.petersonsales.net/drupal.php Let me know if you find it useful or can add it to your document references. It is about 19 minutes long, but it deals with some of the problems you run into if you don't quite know what you are doing :-) Thanks for the help. Jeff [Less]
Posted over 13 years ago by spflanze
I am importing a site that makes frequent use of abbreviations in the file names and paths. It is highly desirable these abbreviations appear in the menus and paths in an automated way. This is not possible because the abbreviations use the period ... [More] character to show it is an abbreviation and in the imported files the paths are being truncated at the first period. In file "rewrite_href_and_src" where the paths are rewritten I can see this is a known issue because there is the comment: And I can understand this is due to the limitations of the string functions available in the XSLTProcessor class. But wouldn't be better to dispense with doing this by xsl and do it in PHP instead so the same function used to for links in the menus, _import_html_calc_path(), can be used? If this function is used for both purposes (menu and content) linking in the content would be far more reliable. [Less]
Posted over 13 years ago by spflanze
I am importing a site that makes frequent use of abbreviations in the file names and paths. It is highly desirable these abbreviations appear in the menus and paths in an automated way. This is not possible because the abbreviations use the period ... [More] character to show it is an abbreviation and in the imported files the paths are being truncated at the first period. In file "rewrite_href_and_src" where the paths are rewritten I can see this is a known issue because there is the comment: And I can understand this is due to the limitations of the string functions available in the XSLTProcessor class. But wouldn't be better to dispense with doing this by xsl and do it in PHP instead so the same function used to for links in the menus, _import_html_calc_path(), can be used? If this function is used for both purposes (menu and content) linking in the content would be far more reliable. [Less]
Posted over 13 years ago by spflanze
I am importing a site that makes frequent use of abbreviations in the file names and paths. It is highly desirable these abbreviations appear in the menus and paths in an automated way. This is not possible because the abbreviations use the period ... [More] character to show it is an abbreviation and in the imported files the paths are being truncated at the first period. In file "rewrite_href_and_src" where the paths are rewritten I can see this is a known issue because there is the comment:<!-- currently broken if path starts with (or contains?) "." --> And I can understand this is due to the limitations of the string functions available in the XSLTProcessor class. But wouldn't be better to dispense with doing this by xsl and do it in PHP instead so the same function used to for links in the menus, _import_html_calc_path(), can be used? If this function is used for both purposes (menu and content) linking in the content would be far more reliable. [Less]
Posted over 13 years ago by jefferis
Hi, I went into my IMPORT HTML settings this morning and found a huge number of injection attempts in the results page and have NO idea how that could be happening, since I did not do it: user warning: Duplicate entry ... [More] 'themes/garland/minnelli/minnelli.info' for key 1 query: INSERT INTO system (name, owner, info, type, filename, status, throttle, bootstrap) VALUES ('minnelli', 'themes/engines/phptemplate/phptemplate.engine', 'a:14:{s:4:&quot;name&quot;;s:8:&quot;Minnelli&quot;;s:11:&quot;description&quot;;s:56:&quot;Tableless, recolorable, multi-column, fixed width theme.&quot;;s:7:&quot;version&quot;;s:4:&quot;6.19&quot;;s:4:&quot;core&quot;;s:3:&quot;6.x&quot;;s:10:&quot;base Does this imply a vulnerability with the plugin or a hack of the drupal install itself? [Less]
Posted over 13 years ago by jefferis
Many pages have imported, some have not, as in my other post. However, of the ones that have imported, most of the internal page links to other pages are not valid. They are looking for the old path, as listed in the bottom of the edit area, but I'm ... [More] not finding them. I plan to run a link checked, but I'm wondering what the best way to FIND the new place where the page is located. Is there a faster method than just stumbling around and copying the entire dynamic link and posting it in the internal page area? Help and direction for this newbie appreciated. Jeff [Less]