I have installed Scald on a new Drupal 7.26 sandbox for testing purposes.

I have a small handful of modules enabled:
Drupal core +
Administration menu 7.x-3.0-rc4
Backup and Migrate 7.x-2.8
CKEditor 7.x-1.13
Views 7.x-3.7

and the Scald 7.x-1.1 suite

I am experiencing an odd issue where I need to save a node twice in order for the "Edit atom properties" (popup) "Link" field to take effect...

1) Add an image (atom) using DnD then right-click/double-click to open properties.
2) Type a URL into the Link field (e.g. http://google.com).
3) Click OK
4) Save node
5) View node but the image is not linked. Viewing source code reveals no "a href" tag.
6) Edit node again.
7) Save node.
8) Link now appears.

If I turn off the rich text editor and look at the code after I first add the link I see this:

<div class="dnd-atom-wrapper type-image context-sdl_editor_representation">
<div class="dnd-drop-wrapper"><!-- scald=1:sdl_editor_representation {"link":"http://google.com"} -->
<div class="image"><img alt="Hippie" src="http://sandbox-d7.dev/sites/default/files/thumbnails/image/HippieChick73.gif" style="height:73px; width:73px" title="Hippie Chick" typeof="foaf:Image" /></div>
<!-- END scald=1 --></div>

<div class="dnd-legend-wrapper">
<div class="meta"><!--copyright=1-->HippieChick73<!--END copyright=1--></div>
</div>
</div>

And when I edit the node again I can see a small change in the code when I switch to plain text editor:

<div class="dnd-atom-wrapper type-image context-sdl_editor_representation" contenteditable="false">
<div class="dnd-drop-wrapper"><!-- scald=1:sdl_editor_representation {"link":"http:\/\/google.com"} -->
<div class="image"><a href="http://twitter.com"><img alt="Hippie" src="http://sandbox-d7.dev/sites/default/files/thumbnails/image/HippieChick73.gif" title="Hippie Chick" /></a></div>
<!-- END scald=1 --></div>

<div class="dnd-legend-wrapper">
<div class="meta"><!--copyright=1-->HippieChick73<!--END copyright=1--></div>
</div>
</div>

The {"link"} attribute has changed from
{"link":"http://twitter.com"}
to
{"link":"http:\/\/google.com"}

Is there something I've missed in regards to Input Filters?
One area of the documentation (https://drupal.org/node/1775714) refers to the "Scald Atom Shorthand (SAS) Filter":

When defining an input format, care should be taken to ensure that the rendered Scald Atoms (probably rendered in XHTML) are not subsequently processed into oblivion by other input filters. In other words, make sure that the Scald Atom Shorthand (SAS) Filter is *after* filters which strip tags.

However, when I look at my Text Formats (/admin/config/content/formats/full_html), I don't see a SAS filter?

Can anyone else reproduce this issue?
It would be difficult for me to tell my clients that they need to save every node twice :(

Any help is greatly appreciated!

Comments

jonesui’s picture

Update:
I was able to reproduce the issue using my steps above here: http://scald-d7.ows.fr/
(the Scald demo site)

jcisio’s picture

The demo site is very old and no longer recommended. You should try it on http://simplytest.me/project/scald_galaxy/7.x-1.x

jonesui’s picture

Okay, I deleted my original install and set up a fresh Scald Galaxy test site.

I can see that there are a few differences in the way the atom code is added to the CKeditor text field...

My original install:

<div class="dnd-atom-wrapper type-image context-sdl_editor_representation">
<div class="dnd-drop-wrapper"><!-- scald=1:sdl_editor_representation {"link":"http://google.com"} -->
<div class="image"><img alt="Hippie" src="http://sandbox-d7.dev/sites/default/files/thumbnails/image/HippieChick73.gif" style="height:73px; width:73px" title="Hippie Chick" typeof="foaf:Image" /></div>
<!-- END scald=1 --></div>
<div class="dnd-legend-wrapper">
<div class="meta"><!--copyright=1-->HippieChick73<!--END copyright=1--></div>
</div>
</div>

The fresh Galaxy install:

<div class="dnd-atom-wrapper type-image context-sdl_editor_representation" contenteditable="false">
<div class="dnd-drop-wrapper"><!-- scald=1:sdl_editor_representation {"link":"http://google.com"} -->
<div class="image"><img alt="HippieChick73" height="73" src="http://sandbox-d7.dev/sites/default/files/styles/large/public/thumbnails/image/HippieChick73.gif?itok=V5bHyhCt" title="HippieChick73" typeof="Image" width="73" /></div>
<!-- END scald=1 --></div>

<div class="dnd-legend-wrapper" contenteditable="true">
<div class="meta"><!--copyright=1-->HippieChick73, by <a href="/user/1">admin</a><!--END copyright=1--></div>
</div>
</div>

It looks like contenteditable="false" and contenteditable="true" were not being applied in my original install.

I also noticed that the CKeditor profile configurations from Galaxy include this under Advanced Options > Custom JavaScript configuration: config.allowedContent = true;

Could this be this issue with my original install?

Its really important for me to figure out what configurations I might need to change because I want to add Scald to a site that is already active, so installing a fresh version of Galaxy isn't an option :(

jcisio’s picture

Category: Bug report » Support request

Yes, try the latest dev snapshot of Scald and reconfigure CKEditor to see if it works, and check if the CKEditor dnd plugin is enabled and the button is added to the toolbar.

Nobody should build site with Scald Galaxy, so it even is not an option for a fresh install ;) Galaxy is just a mean to test Scald, to verify if it works and to have quickly a development environment. You can also check Scald Galaxy code to see how Scald and CKEditor are configured.

jonesui’s picture

I should be looking at the files in siteroot/profiles/scald_galaxy:
.make
.info
.install
.profile
?

jonesui’s picture

Looking at scald_galaxy.install (lines 36-40 and 56-60), I see a "Caption filter" being referenced:

      // Caption filter.
      'caption' => array(
        'weight' => 5,
        'status' => 1,
      ),

But when I view the Filtered HTML format via the admin interface (/admin/config/content/formats/filtered_html) I don't see an UI representation of this filter.

I think this filter could be why my install is having issues.
How can I add this filter w/o using Galaxy?

davidhk’s picture

I have the same problem described in the original post. I am using the current dev version, 7.x-1.1+65-dev.

Create Page. Drop image atom. switch to plain text:

{"link":""}

Back to rich text (ie CKEditor)

Edit Atom properties and type url into "Link" field. Click OK. Switch to plain text:

{"link":"http://try5.gwulo.com/atom/107"}

Save page. Image is displayed, but without any link.

Edit page. Switch to plain text:

{"link":"http:\/\/try5.gwulo.com\/atom\/107"}

Save page. Now image has a link, and clicking it takes you to the target url.

davidhk’s picture

@mordaga, if you look at the configuration for the text format you are using, under "Enabled filters" do you have "Convert URLs into links" ticked?

I find with that filter enabled, I'm getting the problem you describe.

The link looks ok in the editor:
{"link":"http://google.com"}

But when it arrives at scald_render, "Convert URLs into links" has already changed it to:
{"link":"<a href="http://google.com">http://google.com</a>"}

Not surprisingly, Scald doesn't handle this format, and so no link is added to the image.

If I disable the "Convert URLs into links" filter, the link is passed in to scald_render unchanged, and the link is added to the image on the first save.

Does it work the same way for you?

Then any suggestions how to use the "Convert URLs into links" filter and Scald?

I'd usually expect to go in to the text format settings and move the "Convert Scald SAS to HTML" filter in front of the "Convert URLs into links" filter. Except I can't see any Scald filters shown in the list.

jonesui’s picture

@davidhk

I did have "Convert URLs into links" ticked for both Filtered HTML and Full HTML text formats.
When I un-ticked that setting for both formats I get some interesting results...

If I add the image with my text format set to Filtered HTML, I get the desired behavior (the way it works in Scald Galaxy). I can double-click the image and I get the "Edit atom properties" popup. I then add the URL to the "Link" field and save.

However, as you point out, if I try to add a text URL by just typing into the editor, it does not get auto-converted to a link.

What's very strange is that even with "Convert URLs into links" un-ticked for Full HTML text format, I still get the buggy behavior. Double-clicking the image pulls up the standard CKeditor image popup and not the "Edit atom properties" popup.

Furthermore, I'm not seeing "Convert Scald SAS to HTML" as an option for text formats with my fresh Drupal install or in Scald Galaxy. My Scald Galaxy install does have "Convert URLs into links" un-ticked for Filtered and Full HTML (and it has the same issue with adding a URL as text via the editor).

Is there an earlier version of Scald (7.x) that you used that included the "Convert Scald SAS to HTML" option?

jonesui’s picture

I'm pretty bummed that I will be forced to use Media for the two sites I'm currently building :(

davidhk’s picture

Thanks for checking. Then I believe the conflict with "Convert URLs into links" is the cause of this problem.

What's very strange is that even with "Convert URLs into links" un-ticked for Full HTML text format, I still get the buggy behavior. Double-clicking the image pulls up the standard CKeditor image popup and not the "Edit atom properties" popup.

Is that connected with needing to save the node twice? If not it sounds like a separate problem that deserves its own issue.

Furthermore, I'm not seeing "Convert Scald SAS to HTML" as an option

Sorry, I'm confusing things. "Convert Scald SAS to HTML" is just a name I made up to describe the input filter I guess Scald must have. But I don't see it in the list of input filters.

davidhk’s picture

I've just read this page, https://drupal.org/node/1801156, which says that Scald doesn't use input filters, so my earlier guess was wrong.

However it also says that the SAS is converted back to rendered markup by the MEE module before it is sent to the Drupal filter system. Then I don't understand why turning "Convert URLs into links" on or off affects the SAS -> markup conversion.

jonesui’s picture

FYI:
Ticking "Convert URLs into links" for text formats on a Scald Galaxy build also causes the image link issue.

davidhk’s picture

@mordaga, the patch at https://drupal.org/comment/8659777#comment-8659777 adds a simple input filter that converts SAS -> HTML. For me it solves the problem you described in your original post. Please could you see if it helps you too?

The patch applies to the current 7.x-1.x-dev. You'll need to clear caches after applying the patch, then when you configure a Text Format you should see an extra filter "Convert Scald SAS to HTML".

Enable that filter, and in the "Filter processing order", make sure it is higher than "Convert URLs into links"

jonesui’s picture

@davidhk

Short answer is that the patch didn't work per your instructions (on an existing build):

1) Apply patch
2) Clear caches
3) Enable "Convert Scald SAS to HTML" text filter
4) Enable that filter, and in the "Filter processing order", make sure it is higher than "Convert URLs into links"

Following that procedure produced the same results as w/o the patch.

However, after that didn't work I started randomly fiddling out of frustration and had success:
1) Apply patch
2) Clear caches
3) Enable "Convert Scald SAS to HTML" text filter
4) Enable that filter, and in the "Filter processing order", make sure it is higher than "Convert URLs into links"
5) Save
6) Change filter processing order so that "Convert URLs into links" comes first
7) Save
8) Change filter processing order so that "Convert Scald SAS to HTML" comes first
9) Save

For some reason that got the patch working on an existing build.

Your instructions DID work correctly on a "fresh" Scald install.

nagy.balint’s picture

Just to note, we also have this module to deal with the issue:
https://www.drupal.org/project/scald_link_filter

nagy.balint’s picture

Status: Active » Closed (fixed)

Closing this, as likely with the above module, or by turning the filter that causes the issue off, the problem can be solved.