Oxygen XML Forum

Hello,

I have been customising my own templates, including using a custom CSS, and more recently, editing the wt_index.html (and related) files. This has all been going well and I'm impressed with how powerful oXygen is for this.

However, I made the discovery that the search function has broken somewhere along the way. Instead of getting results, it only appears to search in one topic, and return one result (as long as the topic contains the search term - otherwise it returns nothing) The single result is labelled as "null" with a link to the topic, but no other context. Clicking on the topic link takes me to the page with the search term highlighted as per a regular search.

Before I started editing the template's html files, I was getting this issue so I don't think it is related to that. One thing I have found, which makes no sense, is that if the footer is really basic or the default, then it works fine. However, if I put in a slightly more complex footer - which renders fine - the search breaks. By complex, I mean anything other than plain text. Even a <BR> tag breaks it. To clarify - this includes fragments in the text box parameter itself, as well as custom footer files - I have tried both.

I would have probably settled for having to have a really basic footer, however, I've been editing the template's html files now. And now, even when I completely delete the footer (unsetting the parameter), the search remains broken. I have put a lot of work into the template and don't want to start over, and given how bizarre the behaviour is, I have no idea where to begin looking in my changes to try and fix this.

Have you come across this before, or do you have any suggestions on the sort of areas I should be looking at? Given the unrelated nature of the search functionality, and the footer, it does sound like there is a bug somewhere.. but a workaround in the meantime would be fine.

Thank you very much!

Hi,

To reproduce this issue on our side, and further investigate it could you please send us on our support email address (support AT oxygenxml DOT com) a small ample valid project together with your custom template?
Also, in case you have added an XHTML fragment as a parameter to the WebHelp Responsive transformation scenario (for example, in the 'webhelp.fragment.footer' parameter), please send us also the XHTML fragment too.

Regards,
Ionela

Hello,

Thank you for your reply! I was going to send you over our files, but I discovered it can still be reproduced with the standard templates that come with oXygen, and the standard sample dita files that come with WebAuthor - which does suggest it's not an issue with our files or changes I have made to templates.

To reproduce:

1. I created a duplicate of the DITA Map WebHelp Responsive scenario
2. I chose the mobilePhone.ditamap from the WebAuthor samples, but honestly I think it would do the same with any ditamap
3. At this point, search works fine
4. I edited the webhelp.fragment.footer to contain a tag. For example "test <br>".
5. Changing webhelp.fragment.footer to contain plain text and no tags means search works again

I should also reconfirm that the footer displays as designed - it is only when using the search that a problem becomes apparent.

For what it is worth, it seems both & and < characters are what break the search. This is similar to how they stop a .dita file from compiling if they are present within a <codeblock> tag in raw XML, and not converted to < or & as entering code in author mode would do.

The way the search is broken is also fairly inconsistent too. For the sample dita file above, I get the following responses to searches:
- "call" - "Your search returned no results for call"
- "the" - no text at all in the search results window
- "and" - the search results window never loads - the grey horizontal bars stay on the screen, with the "scrolling" effect

I have not been able to reproduce the single result containing null like my dita files have with the mobile phone ditamap but that's not to say it's impossible.

My build of oXygen is "<oXygen/> XML Author 20.1, build 2018061313"

Given most people are going to want to put HTML in their footers, I'm surprised this has not come up before, and it makes me wonder if something is broken elsewhere in my particular installation of oXygen!

Thank you very much.

Hello,

Just to follow up - I have discovered that my XML was not well-formed i.e. I was not closing IMG or BR tags (which I had not realised you had to do). Fixing that has fixed the search.

I am going to assume that an open XML tag is what breaks everything else. Whilst it is fortunately a nice, easy fix, the consequences of an open XML tag were not as expected. I would have expected an error message to this effect, rather than undefined unrelated behaviour which made it very tricky to track down what the actual cause was.

May I suggest finding a way to warn the user if their XML fragments in their parameters are not well-formed? I appreciate it does say clearly that XML fragments must be - but if a user is not aware that their XML is not well-formed, and issues appear in unrelated areas, it can waste a lot of time!

Thank you

Hi,

Indeed, a not well-formed XML fragment inserted in the transformation scenario parameter(s) may cause these issues.
I have added an improvement request to our issue tracking tool to analyze your suggestion and try to find a way to warn the users if the XML fragments inserted in the parameters are not well-formed. Thank you for your feedback!

Regards,
Ionela

I just had the same exact issue and this thread solved my problem.