Posts Tagged ‘Bugs’

Adobe Contribute CS5 Repeatable Regions Broken On Edit

Tuesday, January 25th, 2011

I’ve been working on some Contribute templates for a client. I noticed that repeatable regions weren’t working right. Instead of adding a new item to the region when clicking the plus (or deleting when clicking the minus), the “cursor” would simply move to the next item. The only other reference I could find to the problem was some random, unresolved thread on some website I’ve never heard of.

After a lot of digging around in the code, I figured out the problem. If your template includes another file that has repeatable regions, the repeatable regions in your main template will stop working when you edit the page again. As described, the cursor will move up and down the existing regions instead of adding new regions.

For example, I have a navigation template that has repeatable regions.

1
2
3
4
5
<ul id="nav">
<!-- TemplateBeginRepeat name="Navigation" --> 
<li><!-- TemplateBeginEditable name="Nav Item" --><a href="#">Home</a><!-- TemplateEndEditable --></li>
<!-- TemplateEndRepeat --> 
</ul>

I included that file via the standard PHP include . When editing, Contribute seemed to get confused about the repeatable regions in the navigation when Contribute manually imported the navigation file.

The fix is either to not use repeatable regions in your include files (not an option) or to trick Contribute into not trying to include the included file. Contribute is at least smart enough to know how to do the standard PHP includes. So, I had to break a rule and use eval like this:

1
<?php eval("include('./nav.php');"); ?>

PHP evals the string and ultimately includes the file. Contribute doesn’t understand the code and does nothing, which removes the problematic code and causes repeatable regions to work as expected.

Internet Explorer 7 Heading Bug

Thursday, April 5th, 2007

I try to avoid Internet Explorer 7, or IE7 for short, but I can’t any more. Today was the first time I really had to debug in IE7 and I discovered a pretty irritating bug.

What I wanted to do was put a h2 inside of a div and adjust the margin-top so that it was hanging over the top edge of the div. Imagine a fieldset with a legend.

My code and style sheet were something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<style type="text/css">
div {
	border:1px dashed black;
	background-image:url(../images/sect_bg.png);
	padding:10px;
	margin-bottom:25px;
	clear:both;
}
h2 {
	display:block;
	width:100%;
	height:53px;
	background-repeat:no-repeat;
	background-position:center center;
	margin-top:-33px !important;
	text-align:center;
	background-image:url(../images/blog_title.png);
}
h2 span {
	position:absolute;
	margin-left:-9999px;
}
</style>
<div>
 <h2><span>Heading</span></h2>
 <p>Some Text</p>
</div>

In IE7, nothing happened. In every other browser, the heading moved up. I started playing with the style sheet, removing parts. It turns out that the height and width were the problem. This applied not only to my image replacement, but a plain-old div-with-a-heading-in-it. The fix for my problem was to create a separate IE7 style sheet with the following:

1
2
3
4
5
h2{
	width:auto;
	height:auto;
	padding-top:53px;
}

I was also informed today that my Internet Explorer 6 Virtual PC image had expired. As promised, Microsoft has released a new Virtual PC image. While it’s nice to be able to check against Internet Explorer 6, this refresh cycle isn’t very convenient.

Mozilla JavaScript RegExp Test Bug

Tuesday, July 5th, 2005

There is what some consider to be a bug in Mozilla’s JavaScript engine. Basically, if you run a regular expression with a global switch (e.g. /x/g), JavaScript remembers the last match position. This causes the RegExp to sometimes validate as true, and sometimes as false (alternatingly). The Mozilla guys say it isn’t a bug. However, removing the /g solves the problem.