4.4 rendering extra br tags under content blocks
Hi guys,
I've notices that after upgrading to 4.4, all my content blocks now have a br tag appended when rendered.
It's breaking our layouts.
Not sure how to solve this one.
Stephen
Hello Everybody,
We see also a br tag at the end of each content block. Layout is completely messed up.
Any help appreciated.
Mathias
Same here. Shure would appreciate a quick Hotfix on this.
Markus
Hi,
Count us in. We have a website being launched tomorrow morning which has just been stuff by the extra br inserted by the Content Block.
We have reported this to Telerik as a bug using our partner support.
If we get any news of a fix I will update this thread.
Seth
Hi Guys,
@Sean
Thanks a lot for looking into it
@Telerik
Any chance this is a bug, you will fix it and have a new .dll to be downloaded. I don't really want to start using templates to fix stuff.
Markus
@Telerik:
I'd also like to know if there are plans to fix this behaviour with an update ?
Mathias
Hi,
The issue will be fixed in our upcoming release.
For now the only solution is to map a template for the content block.
Regards,
Victor Velev
the Telerik team
@Victor
Upcomming release as in 4.4 SP1 Janaury or 5.0?
So simply everbody using 4.4 is forced to this workaround?
Markus
My temp fix was to add this style to the page: but it could mess up other styles you may have
An immediate hot-fix/upgrade for this problem would be most helpful! Our site needs to go live in a week and this is making it look bad. Please release it!
@ Sean : Thanks for your solution but apparently it doesn't work for a content block inside a page template...
Hey guys,
I've also added this ViewMap to the settings:
HostType:
Telerik.Sitefinity.Modules.GenericContent.Web.UI.ContentBlockBase
LayoutTemplatePath:
.. to your template...
This will then fix the <br /> issue on templates as well.
Regars,
Daniel
Hi guys,
Our next release is scheduled for February. @Sean's workaround is the best thing that can be done at this point, and as @Daniel properly pointed out, you need to map the template through ViewMap to change the behavior of all content blocks in your projects. Another workaround would be to remove the br tag with a simple jquery declaration:
$(
"div.sfContentBlock > br"
).remove();
February? Seriously??
same issue here, 4.4 completely messed up the styles in our site with the extra <br>. I would like to see it addressed in a hotfix as well.
Doesn't your suggested fix remove all BR tags from the content? Seems it would be more correct to just remove the last matching BR tag:
$("div.sfContentBlock > br").filter(":last").remove();
Hi,
Thanks for the correction, Mark. You are right that removing the last </br> tag is a better approach, since my code would remove all </br> tags in the content block.
All the best,
Jen Peleva
the Telerik team
You can also try this CSS solution:
.sfContentBlock > br:last-child
display
:
none
;
FWIW - just upgraded to V5.0 and seems to still be the same.
For anyone who may want to know,
I just upgraded my website to Sitefinity 5 and this issue has still not been fixed.
Am using raindogmx's solution meanwhile
.sfContentBlock > br:last-child display: none;
To quote Victor on Dec 22:
@Nidhi
I don't believe that the css solution will work for IE8 and earlier.
FWIW: I used the jQuery hack and inserted it onto my base masterpage.
<script type=
"text/javascript"
>
//-- Hack for SF 4.4-5.0 ContentBlock Bug --//
$(document).ready(
function
() $(
"div.sfContentBlock > br"
).filter(
":last"
).remove(); );
</script>
@Nidhi:
"For anyone who may want to know,
I just upgraded my website to Sitefinity 5 and this issue has still not been fixed."
Seriously? Do you mean you upgraded your site to SF 4.4, which triggered the br bug, then upgraded to 5.0 and expected your content to be fixed? (I wouldn't.) Or do you actually mean that if I upgrade my SF 4.3 to 5.0, my content will get corrupt even though I skipped 4.4?
@thomas
Interesting question. Well you should be able to upgrade 4.3 to 5.0 as Telerik claims you can upgrade two versions back. I am interested if 5.0 introduces the same bug as 4.4
@Telerik
If the bug really is not fixed then I must say. Most of us expect known bug to fixed between major releases.
The question remindes me of this question.
If a cat falls of a building it will always land on its feet
If you butter a peace of bread and drop it, it will always land on the side with the butter on it.
Question
What happens if you would put butter on the back of a cat :-)
"If the bug really is not fixed then I must say. Most of us expect known bug to fixed between major releases."
They can't fix all the bugs, obviously, but content corruption bugs should be given the highest priority.
This is really frustrating. I do wonder if they should put a little (or a lot) more emphasis on bug fixes rather than releasing new features.
@Thomas
I don't believe its actually a content corruption bug - but rather, it's a rendering bug. The extra br is not actually inserted into the stored content (first thing I checked) but simply added during the rendering, by the control's code/template. Thus fixing the bug should "remove" the extra br seen on 4.4 sites.
@Markus
Yep, it's the same bug. I had skipped 4.4 as there was nothing there I needed and I preferred not to implement a hack to deal with something that was going to be fixed in the next release. Unfortunately, as we now know, it wasn't fixed, and so I've implemented a suitable hack, in a place where I know I can easily locate and remove it, when no longer required.
I posted a highly discussed thread a month or more ago about their release and bug resolution practices. Essentially, Sitefinity said they are driven by aggressive new technology releases and that's what their customers want.
I beg to differ in opinion based on the fact that aggressive new technology does none of us good if it's bug-laden. Furthermore, they don't believe in iterative "bug releases". There is always new functionality in a release and bugs come second. Many of us are still waiting on fixes for bugs introduced multiple versions ago. Right now features in my sites are crippled or jerry-rigged as a result of OBVIOUS, silly bugs (such as the injection of the unwanted <br/>) we're still waiting on fixes for. Because I don't get a patches-only service pack for my installs, I have to wait for releases like 5.0 that I can't even upgrade successfully just to get SOME of my bug fixes in place because its full of new technology that is breaking my existing sites. As a developer and IT professional, this is a maddening practice.
I'm supposed to be having a meeting with my superiors tomorrow to discuss how the testing of 5.0 and 4.4 to 5.0 upgrade tests went. Given how badly it's gone, I am prepared to go in to the meeting tomorrow and recommend we drop Sitefinity. The reason we purchased it was because it was supposed to help relieve me and my team of the hours required to accomplish our web-based business development goals. I've only been on this platform for a year (4.0 to now) and being on Sitefinity has actually taken MORE of my team's development hours than had we just stuck to our custom asp.net website and homemade SQL backend. The sad thing is, we're not even doing anything fancy with this software. We just want the out-of-the box stuff to work like it should.
@MB: thanks for the info. I assumed it was a content corruption bug, just like 4.2 SP1 corrupted image tags within content blocks.
That said, I don't understand why the fix didn't make it in 5.0, as Sitefinity admins said it would. But history repeats itself, as the same thing happened before on multiple occasions. Do you know the saying "Underpromise and overdeliver"? It's the other way around, here.
Hello,
Apologies for the confusion, guys. We somehow missed this one.
@Thomas - The problem is really with us this time, but I do no think we do it that often. We've provided a quick fix, but failed to include a fix in 5.0, since it was shifted for a release earlier.
I'll make sure to include this in the major version of Sitefinity, until then, please use the solution provided below.
I'd like this fixed too.
I'm using this workaround for now.
@Georgi,
What solution provided below?
Yes, where is the solution? There are several things like this that are wasting my time because I first think I'm doing something wrong, or there's some hidden checkbox in the seemingly endless and confusing options provided in the "advanced" button of the widget's settings. I get to a forum like this, and find I have to implement a workaround. When it does get fixed by Sitefinity, I'll have to undo the workaround - everybody here will. Add this in with other overlooked content problems that require hacky workarounds (like not being able to predetermine margins on floated images on a blog). I'm not surprised that bugs like this don't get fixed. It makes a better press release saying version 5.0 has new this and new that, rather than fixing bugs for the people already using it.
Here is the workaround I am using. It finds the last <br /> that is a direct child of .sfContentBlock and hides it. Someone replied with one before that would just hide the last <br /> tag, which you may not want to do in all cases.
.sfContentBlock>br:last-of-type
display: none;
@Kurt. This is fixed in 5.0 SP1, no more br tags
Looks like this issue has resurrected in 7.0? Anyone else noticed it?
Hello Antonio,
We have a known issue where <br> tags are added after the content when a content block is edited in Firefox. We have logged this issue in our bug tracking system and hopefully we will be able to fix it for our future releases. Here is a link to the feedback portal where you can track its progress and vote to increase its priority.
Please note the issue is not reproduced in other browsers.
Regards,
Sabrie Nedzhip
Telerik
Hi Antonio
I've just migrated several sites to 7.0
and I'm also getting the pesky extra <br> tags
This happens in Firefox but no problem with IE 11
Martin
Hi,
Thank you for the additional information. You can follow the item in the link my colleague Sabrie sent in order to receive notifications if the status of the bug is changed.
Regards,
Stefani Tacheva
Telerik
Thanks Stefani :
Regards
Martin