@20after4, any chance there's a stack trace for this in the webserver error logs? I can't immediately figure out how to reproduce this locally.

The "Attempting to add more metadata after metadata has been locked." error means that we've supposedly finished rendering the page but some component is trying to add more metadata (usually, Javascript behaviors) to the page too late in the process, but it isn't very helpful on its own in pinpointing what the actual problem is. I'm not immediately sure how to reproduce this locally -- copying the description and image comment into a local mock didn't raise any errors.

I'm guessing it might be something like "use a certain specific remarkup rule in an inline comment" but I'm not having much luck figuring out what rule it might be.

We can probably make this error message more informative if we don't have any luck with the stack trace.

I did run into one not-likely-related-but-easily-reproducible-and-sort-of-adjacent error in poking around here:

• In Pholio, leave an inline comment on an image, but don't provide any text, to produce this:

I toggled developer mode on for a moment and managed to get a stack trace:

Could this be related to the custom footer markup? The code in question hasn't changed in a long time but I suspect maybe it's related to changes in the remarkup rendering code that's adding metadata where it didn't previously?

Thanks!

The renderHTMLFooter() method does a bunch of Javascript stuff and isn't actually related to the page footer, but PHUIRemarkupView and renderObjectRefForAnyMedia() were enough of a hint that think I have a reproduction case locally now -- let me figure out what I actually did and this will likely be fairly easy to fix.

D20647 should fix this. It isn't very satisfying as a general resolution.

The issue is that we have a Javelin behavior which passes a View as a configuration parameter, e.g.:

Javelin::initBehavior('quack', array('view' => $some_view_object));

Later, we render all registered behaviors in a single block, and lock metadata before rendering them. However, $some_view_object may wish to register metadata during rendering. The "fix" is to hsprintf(...) it earlier, which explicitly serializes it.

It would probably be reasonable to do this:

• mark the behavior list as locked;
• serialize the behavior list, working one behavior at a time, either doing try/catch for each behavior or passing keys into the stack as labels and doing try/catch for each value serialization;
• mark the metadata list as locked;
• serialize the metadata list -- working one block at a time is probably pointless since we can't really provide any useful context about a weird piece of metadata.

There's also no real reason we need to apply these locks at all; we could individually serialize the behavior and metadata lists repeatedly until both are empty, and allow metadata serialization to yield behaviors and behavior serialization to yield metadata, with some hard cap like "if components yield complimentary components more than 32 times, assume we're stuck in a loop with a goofy behavior and metadata block yielding one another".

Offhand, I can't really come up with a legitimate use case for having metadata serialization register a behavior, though.

Anyway, probably the kind of question that's ripe to be revisited when we're forced to mess with this stuff for Quicksand or something like that.