Forum OpenACS Development: Error on upgrade to 5.3.2

I am recieving the following error after upgrading 2 sites to 5.3.2.

"elements(sec_fieldset)": no such element in array
while executing
"lang::util::localize $elements(sec_fieldset)"
("for" body line 6)
invoked from within
"for { set __d17_i 1 } { $__d17_i <= ${elements:rowcount} } { incr
__d17_i } {
upvar 0 elements:$__d17_i elements

I tried to use both the compat templates (restarts server every page load), and the new templates, other errors like:
charset=[ad_conn charset] throws an ns_conn error about charset, and still doesn't fix the problem.

This is a killer problem as I can't access admin. At least using my original custom templates works for my user pages.

BTW, these are standard admin pages from OACS. I can't imagine why these problems happen in a stock upgrade.

Jon,

Which pages give you this error?

Seems like its only should show up in forms that use sections, if I am not mistaken.

This isn't only for dotlrn of course. Having standard compliant accessbile HTML is a goal for the entire toolkit.

shared/parameters?package%5fid=461&return%5furl=%2fadmin%2fsite%2dmap%2f

as you can see it is a plain old admin page.

Jon,

Can you explain what not marked correctly means?

It looks like the files in CVS are ok.

Well for some reason on these 2 sites, after upgrading from the repository, the actual files for acs-subsite were not created and the old dir not named .bak.

I hope that makes sense. It may have been something on my end but 2 sites out of 4 would be a strange thing.

I know for a fact that upgrade from the repository was tested (actually it's more common to have upgrade from the tarball not tested).

Yet again another change to dotlrn messing with non-dotlrn code.
This is getting to be a broken record.

We've been doing our best to put an end to this, but as Dave mentions above, while changes to make HTML generated by the toolkit validate, and also meet accessibility standards, were driven in the short-term by the needs of the .LRN community, it's something that needs doing for the toolkit at large.

In particular, the accessibility standards will have the force of law in the EU before long, and here in the US there are ADA implications, too. So it's important.

And certainly no one's going to argue that generated valid HTML is a bad thing, right?

And I might add that moving more and more look-and-feel stuff to CSS, to make customization easier, has been a goal now for some years. We've put it off over and over again because we've known there'd be short-term pain once we start taking big steps in that direction. Finally we've decided to bite the bullet and move forward. We're trying to make it as easy as possible.