bsy-web

@josh: Yes, most recent edit to have “Wrap lines” unchecked by default was only to change:
/codemagic/js/codemajic.js, line 6: wraptext_active: true to wraptext_active: false

I verified on my local build on Chrome, Opera, Safari and Firefox. All started CodeMagic modal window with wrap line option unchecked, allowing for standard editing.

If the user checks the option, same problem appears, in which case they just need to uncheck again.

Please confirm in your local build.

Updated git-hub issue related to “Wrap Text” not functioning as expected: https://github.com/tinymce-plugins/codemagic/issues/7

Simple work-around for having option as unchecked for default. Considering others have experienced it not working as well, makes sense to have it unchecked by default.

To have the CM editor open with option unchecked by default, chance following line/code:
/codemagic/js/codemajic.js, line 6: wraptext_active: true to wraptext_active: false

I did a quick look to see if whole UI element could be greyed out, but it was not obvious to me.

Hi,

Thanks for asking. I found when using this plugin that the PDF content is limited to size of primary div (which makes sense). If the content could be shown in an optional overlay, like a light box, it would be very useful.

I’ll see if I can use exiting lightbox plugin to show content from your short code.

Pls let me know if/when you want help testing if any of these features make it into the plug-in. Here is a sample page that would use the plug-in:
https://yogavision.net/sannyasa-peeth/avahan/may-jun-2012-year-1-issue-3/

In example page above, PDF is linked to Google Document Reader until point were PDF can be loaded natively, and readable.

Josh,

Did you check out the latest version of CodeMajic for inclusion in current version of UTMCE or just add the updated beautify-html.js file to version of CodeMagic you have been using so far?

Thanks

Hi Josh,

Thanks for bringing me in the loop. I never tested my changes against the latest version of CodeMagic of GitHub, only against the versino that was bundled with the UTMCE plugin I was running at the time. It’s possible the logic between the wrap-text feature (which I did not have) is colliding in some way.

I browsed the thread you referenced. Last comment from Marventus has my attention: “We have determined there is an issue with the CodeMagic addon and the cursor position when the “Wrap Text” option is enabled (checked). We will definitely try to find a solution for this, but in the meantime, unchecking that option should get you going nicely.”

I think wrap-text option was added by Yonus about 6 months ago (i.e. I didn’t implement it). I also recall submitting bug issue related to it not working. That said:
– the version I developed on was the older version of CodeMagic without that option in place
– did not touch any TinyMCE UI logic (only edited single .js file which addressed parsing logic)
– only developed and tested on FireFox

It’s a crunch week at moment, but early next week.
– I’ll try and replicate what everyone is experiencing
– test my changes on Chrome/Safari. Working on Mac and IE not easy option at moment.

Haven’t experienced any issues with UTMCE v4.0.8 on WP 3.3.1 or v4.5 on WP 3.5 – but again on FireFox only.

Peace

@josh,

I’m glad it’s working for you. I haven’t seen the pull request merged either.

I only tested the code with UTMCE v4.0.8 as I’m dependent on WP 3.3.1 at moment, but am glad it is working in the latest version of your plug-in.

There are some other CodeMagic enhancements in the pipeline contributed by others which I may try and merge in the next few months (local storage of settings, returning to same line after reformatting, line wrap, etc.)

I’ll keep you posted if there is forward movement.

Peace

Hi Marventus.

I interpreted their reply as acknowledging the issue is on there end.

I think they were clarifying for me that updating CodeMagic does not necessarily mean Ultimate TinyMCE will integrate those changes (the latest version, for example, (supposedly [I have not gotten it to wokr for me]) includes text wrapping as a new option but the current version included in UTMCE does not include it.

If y’all can come up with some more test cases, to ensure nothing has regressed, that would be awesome. Valid HTML, invalid HTML, nested cases, unclosed or unopened tag-pairs, etc. will help identify any other issues.

Thanks.

Hi Josh.

I have been looking at the CodeMagic files, specifically beautify-html.js. It handles the tag parsing and indentation formatting logic.

I uncommented an else block in the original code of that file which actually keeps inline tags on the same line. I think it was commented out to make the code indent more like standard programming source, but the programmer may have overlooked how white-space is interpreted by browsers for inline tags.

beautify-html.js: lines 219-223: Uncomment the following:

/*else if (tag_check === 'a') { // do not reformat the <a> links
        var comment = this.get_unformatted('</a>', tag_complete); //...delegate to get_unformatted function
        content.push(comment);
        this.tag_type = 'SINGLE';
      }*/

Uncommenting the above will keep the a-tag on one line. The same code can be duplicated for all inline tags (e.g. em, strong, i, sup, sub, …), which is what I am doing for now.

I will implement a fix so that any tag which is in an “inline” array, will remain on one line. Then anyone can add or remove elements from the array as required (e.g. as HTML specifications change).

The next issue, once the above fix is implemented, is when a character is adjacent to an inline tag (pre or proceeding it). The parsing logic immediately puts it on a new line and a browser will render the newline as white-space.
Example:

<p>This plug-in is <em>super</em>-<strong>helpful<strong>!</p>

will show as

<p>
     This plug-in is
     <em>super</em>
     -
     <strong>helpful<strong>
     !
</p>

which outputs as: This plug-in is super – helpful !

I am about 75% through wrapping my mind around the tag parsing logic and intend to submit a fix by the end of the week which addresses the above issues. It’s starting to become a major drawback as our site grows to manually correct spacing in the visual editor after editing in the CodeMagic HTML editor.

Again, just for my own sanity, how have others been dealing with the introduction of white-space when using the CodeMagic HTML editor?

Peace

https://github.com/tinymce-plugins/codemagic/issues/6

Sorry if you get this question often, but I wanted to follow up on it as well.

You’re probably aware Ultimate TinyMCE integrates CodeMagic for syntax-highlighted HTML editing, but it formats the code in a non-HTML-friendly manner (i.e. the indentation introduces unwarranted white-space for tags like a, em, strong, sup, …).

If I recall an earlier post of yours you mentioned there are other inherent difficulties in plugging in an editor with TinyMCE/Wordpress. Have you started the effort but found yourself blocked by the architecture of WordPress or other issues?

If you have any notes and are willing to share, please post. During the last year of trying to find a simple external editor solution, I think many are looking for a way to use a robust code editor which will pass HTML-accurate formatted code back to WP with out it being further processed.

It’s all Text (FireFox add-on) comes close as an external solution, but an integrated solution would be ideal.