CKEditor Fallback for old atom markup

Thanks for the report.

However, can you provider more information on why the data cannot be retrieved?

It seems to me that it should work in all cases, as it just reads the markup , fetches the sas code, and then parses the sas to have the data. So if that does not work, then likely the html is wrong for some reason. Can you copy paste the erroneous html?

I just tested on an older site myself and found no such issues.

It would be nice to know what was in the "sas" variable, after var sas = el.children[0].getHtml();
Because i think that the only way this can fail is if inside "dnd-drop-wrapper" you have something else than the shorthand the [] placeholder, or you dont have the placeholder there at all for some reason. Maybe that is because its an already broken atom?

Also i would not use the javascript alert, as if you have many broken atoms in a single page, there would be a lot of alerts.

I suggest the following change instead.

To check if data is undefined, as when the match fails it will be undefined.

Then if its undefined, we can check if its html can be salvaged. Trying to convert html to sas first, and then sas to array.
For some reason the html2sas function did not take care of extra options parameters, I've put that in for now.

Then if its html cannot be salvaged, then we do what you have suggested and remove the classes.

So far it passes my tests.

Ok, here is a better version.

I added a new js function.
It only checks for the beginning html comment. And simply returns the sas representation.

So so far how the patched version works is that:
1. It finds the sas without problem -> converts it
2. It finds the sas but it has some values missing -> malformed sas, if the sid is missing then cant use the sas to convert it to markup anyways, and so it wont appear on display even with the old code.
3. It does not find sas code -> checks if the html comment starter is there at least, even if everything else is missing, then if its found, it uses that to convert it into a sas. Then we got the sid and can use it to convert.
4. It does not find sas code -> there is no html comment starter -> unfortunately then we cannot convert cause we have no sid anymore, so we remove the classes to not try to convert this kind of atom anymore, and keep it as a static html snippet.

More on point 2 of the above:

The sas2array function's return value will be stored in data.
The sas2array will only return something, if it has at least a match for the shorthand pattern. So it will only return something if there is a shorthand in the elements markup. And in the pattern after scald= there must be at least one number in order to get a match, thats because of the + sign.
So if sas2array returns something, then it has to be a shorthand and it has to have a sid. So checking for sid is not necessary.
If however sas2array returns nothing, then it will be undefined, and that is checked in the new patch as well.

Great, thank you!

The normal behaviour is that in the node itself (when viewing through devel module for example) you should see something like "[scald=1470:sdl_editor_representation]" inside the two divs. Then the upcast script will turn that into the proper widget, and then after the first save it will convert it to the proper markup.

In your case if i understand correctly, you have the markup there and not the sas code. In that case since the sas markup match will not apply, the new code (if you applied the patch in this issue at comment #6) will turn that markup into the correct sas code, and then replace it into the correct widget, but then still have to save the node to properly fix it. (It will only check for "<!-- scald=1470:sdl_editor_representation -->")

So unfortunately i cant see anything wrong here, the code should work fine.

Please use my patch, need to debug with that.

I feel like this is a misconfiguration and not a bug so far.

I will pm you for access.

@Cellar Door

This is the content of #12, just indented to show the DOM structure :

<div class="dnd-atom-wrapper type-image context-sdl_editor_representation">
  <div class="dnd-drop-wrapper">
    <!-- scald=1470:sdl_editor_representation -->
    <div class="image">
      <a href="[url]">
        <img alt="...button.jpg" height="93" src="[url]...button.jpg"
          title="...button.jpg" typeof="foaf:Image" width="632" />
      </a>
      <div class="dnd-legend-wrapper">
        &nbsp;
      </div>
    </div>
    <p>
      &nbsp;
    </p>
  </div>
</div>

as you can see :

<!-- END scald=1470 --> is missing in div class="dnd-drop-wrapper"

div class="dnd-legend-wrapper" has been moved inside div class="image"

Obviously, this code have been manually edited, it cannot have been produced by any version of scald software...

But the patch in #6 fixes even that situation.

Thats why it should work fine with my patch.

@Cellar Door

Can you double check if you have done all the steps when converting to widget support? At https://www.drupal.org/node/1775718

@Cellar Door
That means that your markup does not contain the proper div for the widget, as the widget div actually contains sid and such.

So it seems like that you dont have proper widgets.

Hard to see whats wrong without more information or an access to the site unfortunately.

Will commit patch #6 tomorrow, since it just adds a fallback to the upcast when the data is undefined, so should not impact any previous logic there.

And hopefully this will be the last commit before 1.4 :)