Occasionally in Designer, I am getting strange behaviour where when I load up the form, all of the @field@ placeholders are replaced with the text which was there in Preview mode before.
I thought this was previously caused when I saved the while still in Preview mode but now the behaviour seems sporadic.
Please advise - is this a known issue?
NB: This has been seen across versions and installations.
Do you happen to have these problematic items set with a class named ādynamicā?
I donāt believe so - it seems to happen to the entire document in one go.
Itās dangerous as you donāt notice whilst continuing to develop on Preview mode for layout purposes, you save the file and then realise youāve lost all of your placeholders.
It is a known issue, unfortunately, an inconsistent one, that we have yet to reproduce at will in order to find the source and fix it.
I suggest you open a technical support call through our website. This way we can compile example of the problem and try to pinpoint the source. It would greatly if you can remember what you where doing the last time it happened or better, being able to reproduce it at will.
Thank you. I will have one of my colleagues update the thread - he has seen this most recently and will be able to tell you if there is any repeatable behaviour which causes it.
Iāll also put a ticket in with local support to get it recognition in the JIRA world.
J
As jim3108 said, I had this happen to me today. Iām not sure exactly what triggered it, as I was working on a different part of the form, but when I looked back all of my @tag@ had been replaced with the actual data, rather than the @tag@ variable. Unfortunately Iād saved since it happened, and made enough changes that I was unable to just revert back, and so had to go through where all of the @tag@ should have been and call them again properly.
For the job Iām working on, each div just has a different @tag@ within, placed around a PDF background. I havenāt deliberately set anything to dynamic, when I go to Preview mode it does assign each < div > as āspan .ol_wrapped .dynamicā.
However there was no effect on the recurring items that I had within a detail table, they werenāt affected by this.
Hi hamelj,
I thought I reported this issue before or at least mentioned it to one of OLās employees. The only way I can reproduce it 100% is when you go into preview mode and copy/paste a positioned box. After that the new div will have the value of the field and not the @field@ when going back to design mode.
If you look at the source code after this happens there is no difference in the code. However when you click on the original divās text in preview mode, the text has a class called ol_wrapped dynamic. The newly created div that is now ābrokenā does not have a class.
Hope this is somewhat useful.
Regards,
S
I think this is because of the class dynamic. It has been reported already but I will do a follow-up on this.
If any other way to reproduce the behaviour are found, please post it here or open a technical support ticket through our website.
I have reported the similar behaviour to our R&D.
Hi hamelj,
I just found another way to trigger this. Iām using the same script on multiple sections and wanted to add the reference number to another section. So I place a positioned box while in preview mode and added the @field@ and ID to it. Once the ID was in and I clicked elsewhere for it to apply, the placeholder immediately changed to the fields value. When going into Design mode the value of the field remained and it did not revert back to @field@. I hope this slightly different approach helps.
On a different topic. Did you know you can have multiple divās with the same ID and they all work on a single section/page. Is this dangerous?
Regards,
S
@Sharne: the HTML spec states that all IDs throughout a page must be unique. However, we decided not to enforce that rule (just like many browsers donāt enforce it either) because many HTML coders and sites use duplicate IDs on purpose (most obvious example being YouTube - check out how many <div id-"button" ā¦> there are on the main page!).
Plus, enforcing it would require Connect to constantly monitor what youāre typing/pasting and notify/prevent you whenever you duplicate an ID, which I have a feeling would quickly become a PITA and might hinder performance.
I personally donāt think thereās ever a good reason to use duplicate IDās but since the technique is being used and might be expected of Connect, we canāt prevent it from happening.
Hi Phil,
I was just wondering because Connect does enforce unique IDās. When having a div with an ID and trying to add another div and giving it the same ID Connect gives an error that reads āMust be uniqueā. However to circumvent that one can copy a div and then the duplicate IDās are ok. Hence why I thought it could be a bug.
Donāt get me wrong, I like to duplicate as it reduces the amount of scripts be it text or standard.
Regards,
S
Yep, sorry, I should have been more clear for other readers who might happen upon this post: Connect does in fact prevent you from using duplicate IDs through the GUI, but it will let you do whatever you want if you work directly in the HTML source code.
Thanks for pointing this out.
Hi,
Itās 2025 and we still have this issue? Albeit an old template that does not use handlebars, this annoying issue has reared its head once again. Unacceptable.
Should I convert my old templates to use handlebars? (Or is handlebars also affected by this?)
How do I do that without hours of work?
Any issues converting a template to use handlebars that I should be aware of?
Regards,
S
Hello @Sharne, thank you for reporting this. Can you please open a ticket via our support portal for this and, if possible, share the OL Connect resources by which you are facing the issue? Because this issue has already been fixed in version 2021.1, as far as I know.
Hi Marten,
I actually had this issue in 2021.1 with a very complicated municipal account. Took ages to fix due to not having the Project/Git feature in that version. Updating to 2024 and then 2025 I thought I would not see it again.
All I can do is give OL the broken template. Is there anything else you would want me to share in the ticket before I open it? (Specific log locations)
Iām not sure if it happend today or yesterday. Client asked for me to add a QR code, Pay Button and some new logos/text to the template and when debugging in Workflow about an hour ago I noticed this issue.
Please advise.
Regards,
S
The Designer logs may be helpful plus, if possible, also the template from before these changes were applied.
Ok, will do, thanks.