Take a look at ~/sys_resources/rx_ephox.js, in the block starting on line 267.
The blue arrows serve to indicate the presence of an inline template in the editor. You haven’t explained why you don’t want them, but you should be able to suppress them with edits to the above file.
We want the blue arrow markers under EditLive, but NOT when previewing and publishing the content item. Under 7.0.3 the blue arrow marker images appear both when previewing and after publish, which is very undesirable
Adding the span tag to var ___blockTags in file /apps/percussion/Rhythmyx/rx_resources/ephox/rx_ephox.js removes the inlinemarker images and so NOT publish the marker images. This makes the issue NOT a showstopper anymore, but we are also NOT able to see the blue arrow markers under EditLive either
We definitely want the blue arrow markers for the NON-block inline variant, like inline variant, to differentiate inline template from inline link. I checked the /apps/percussion/Rhythmyx/rx_resources/ephox/rx_ephox.js. It is the same from 6.7.0. Clearly the inline marker images are added for inline variant under 6.7.0. Somehow Rhythmyx 6.7.0 EditLive enhancement or extension removes the marker images and then replaces with blue arrow markers via CSS styles. We can see this from the code view which does NOT have the code snippet < img alt="@inlinemarker@" height=“8” src="…/sys_resources/images/inlinestart.png" width=“9” / > at all
Under 7.0.3, Rhythmyx EditLive enhancement or extension does NOT remove the marker images anymore. This is ok under EditLive editor, but the assembler and publisher should NOT display the marker images when previewing/publishing the page. I really like the 6.7.0 way though
Please let me know how we can add back the blue arrow markers only under EditLive editor, but NOT when previewing/publishing
There is an Ephox EditLive plugin that swaps out these images when switching between code view and wysiwyg view. The Java .jar file for this on the client is cached and may not be updated on upgrade of the server to 7.0.3. This is different that the Java Cache itself that can be cleared from the java control panel app and stores the ephox applet and content editor applet. On windows 7 you can go to C:\Users{user}\AppData\LocalLow\Ephox and delete the contents ( if a file is locked you may need to close your browser). This may not affect an item that now has these arrows coming through (the html may now have these embedded, you may need to remove the extra elements in source view) but should stop this from happening with newly inserted inline snippets.
Tested this issue on our development instance running 7.1.x. We enabled “allowTrueInlineTemplates.” Upon inserting a inline variant we see the blue arrows indicating the inline template; however, the images remain displayed after switching between code view and WYSIWYG view, previewing the content item, and publishing the content item. Should the sys_EditLiveFormEncode output transformer extension remove these images upon preview/publish?
Tested this issue on our development instance running 7.1.x. We enabled “allowTrueInlineTemplates.” Upon inserting a inline variant we see the blue arrows indicating the inline template; however, the images remain displayed after switching between code view and WYSIWYG view, previewing the content item, and publishing the content item. Should the sys_EditLiveFormEncode output transformer extension remove these images upon preview/publish?[/QUOTE]
Yes these arrows should be removed by a combination of sys_EditLiveFormEncode and the rxEphoxExtensions.jar file ephox plugin. I do see a bug related to this jar file not getting updated on upgrade. You may want to compare the size of these two files and if they are different copy the sys_resources version which should be upgraded to rx_resources, and then clear out the client ephox cache as in my last post.
Our rxEphoxExtensions.jar is the same file size across all locations. For a further confirmation it is the same file size as the rxEphoxExtensions.jar distributed in the 7.1 release candidate.
Same ephox Jar for us as well (same hash) between the two directories. We have 7.1.0, patch CMS-225. I cleared out the cached files as you suggested, but no luck (I also cleared out the Java cache and certs). Both Chrome and Firefox do the same thing…
It is the rxEditLiveFormEncodeDecode.jar code that is doing the removal of these images. In my version even pasting your snippet contents if I switch between wysiwyg view and source view the images disappear in the source. This code does not care about where the images appear in the html, but should remove these images when switching and on save as long as the alt tag is @inlinemarker@. There three reasons why this may not be happening.
rx_resources/ephox/plugins/rxEditLiveFormEncodeDecode.disabled may not have been renamed correctly to rxEditLiveFormEncodeDecode.xml.
rxconfig/Server/server.properties may not have allowTrueInlineTemplates=true
The correct rx_resources/rxEditLiveFormEncodeDecode.jar may not be cached on the client. Did you check this is the rx_resources version is the same as the sys_resources version.
Ephox may not be loading the jar correctly.
If the above config is confirmed could you please, turn on the Java console and trace from Java control panel. Turn on ephox debugging from the ephox icon in the ephox menu (you will need to restart the browser) Send the results to tech support in a new ticket so we can track this issue. I will analyze this and will post the outcome if we work out what is happening here.
Will do… Although I had already created a TS ticket five days ago…
But just to clarify, if it saves the inline lines without those markers, does it “recreate” them when reloading that item later on? If not, what’s the point in having those markers in the first place if it only shows up that one time you create the link? (And if this is the case, I’ll probably see if i prevent the images from appearing altogether because this would be inconsistent behavior for the end user). Right now, in 6.7 those markers show up in ephox all the time, but not when you preview or publish the item (as indicated by Hua). I assume the 7.1 behavior should be as it was in 6.7?
It seems that a css rule that puts a box around it that is only applied when shown in ephox is a better solution than to have extra image code (Just wishful thinking I suppose… but should be entirely doable since ephox does have a way to load a separate stylesheet)…
The ephox plugin recreates the images when in the wysiwyg view, and removes them after for source view and when saving. In Ephox you create a source filter this allows you to process the html on the way in and out of wysiwyg view for this purpose. When the plugin is working correctly you should not see the image in the source at all. I might be wrong but I think putting a border around would not work because of ephox’s limited support for css, we cannot use a div as this would cause ephox to break the paragraph and we cannot use span as we cannot apply a box arount a span as a style in ephox.
It looks like our problem was with the .disabled not being renamed to .xml. However, once we did this (and restarted the server), I get an error in EditLive and this prevents the applet from loading (gets stuck at 59%…):
Exception in thread "Thread-61" java.lang.NoSuchMethodError: com.ephox.editlive.AppletBean.getParameter(Ljava/lang/String;)Ljava/lang/String;
at com.percussion.ephox.sourcefilters.PSFormEncodeDecodeSourceFilter.filterIn(Unknown Source)
at com.ephox.editlive.java2.editor.EPane.doTimedSetSource(EPane.java:3674)
.....
I did clear out the local java cache files (and the stuff in the ephox directory), the jars on the server are the same (have the same hash), and we have the correct property in the server.properties file… any other suggestions (the above error is different though, so I would say we are getting somewhere… )?
There was a difference between
rx_resources/ephox/plugins/rxEditLiveFormEncodeDecode.jar
and
sys_resources/ephox/plugins/rxEditLiveFormEncodeDecode.jar
We copied over the sys_resources jar to rx_resources and that appears to have solved our problem (with the java.lang.NoSuchMethodError error).
Restarted, logged in, and it appears to work as described.
So in conclusion, after the upgrade to 7.1, we needed to
Replace the rxEditLiveFormEncodeDecode.jar in rx_resources with the one in sys_resources
Rename rxEditLiveFormEncodeDecode.disabled to rxEditLiveFormEncodeDecode.xml (this apparently was changed by the upgrade)
Probably clear java cache on client (I will need to verify that we have to do this)
We have the same issues as this post described and we have done all things as suggested, but that still does not solved the problem. Any ideas what we can do next?
I will assume that you have enabled “allowTrueInlineTemplates”? (I would think yes, as that is how you are supposed to get the arrows… but just checking)