Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load unminified TinyMCE when SCRIPT_DEBUG constant present #639

Merged
merged 1 commit into from
May 4, 2017

Conversation

aduth
Copy link
Member

@aduth aduth commented May 3, 2017

This pull request makes a simple change to load the unminified version of TinyMCE when the SCRIPT_DEBUG constant is specified as a truthy value, thus facilitating debugging of TinyMCE internals.

Testing instructions:

Verify that the editor loads with and without a SCRIPT_DEBUG constant defined as true.

https://codex.wordpress.org/Debugging_in_WordPress#SCRIPT_DEBUG

@aduth aduth added the TinyMCE label May 3, 2017
@nylen nylen added the [Type] Build Tooling Issues or PRs related to build tooling label May 4, 2017
@nylen
Copy link
Member

nylen commented May 4, 2017

I didn't realize this, but SCRIPT_DEBUG defaults to true if you're running a source checkout of WordPress. So this changes the default behavior for me, which seems reasonable, and this PR works as intended: I get the minified version again if I do define( 'SCRIPT_DEBUG', false );.

Separately, I wish we weren't loading these scripts from the network at all (#647).

@aduth aduth merged commit 2e68306 into master May 4, 2017
@aduth aduth deleted the update/tinymce-min-script-debug branch May 4, 2017 14:44
@caraffa
Copy link

caraffa commented Apr 28, 2018

Sorry, I've checked. Your code is simply loading an uncompressed vesion of tinymce.min.js when DEBUG is truthy. I'm not that smart with pure JS but for sure debugging a min version of a script is a hard task. I think you should provide a way to to debug with an unminified version.
Thanks

@mcsf
Copy link
Contributor

mcsf commented Apr 28, 2018

I’m not sure I understand. The scripts in question are vendor builds, one of which is minified (or uglified, depending on the jargon), while the other isn’t.

While the latter may be a large and at times cumbersome file for a human to digest, it is nevertheless the full unminified source as provided by the vendor. It is the product of the vendor’s own build process.

In this sense, there is no deviation from what WordPress core does, unless I’ve missed the point of your comment. Or is this about pulling the TinyMCE nightlies?

@caraffa
Copy link

caraffa commented Apr 29, 2018

Hi Miguel.
Thanks for your considering my comment. Actually, yesterday I managed to resolve the problem I was after without digging to much into TinyMCE scripts. Neverthless, since you're asking, I'll clarify my point. As you can see here (but I'm sure you fully know that) this line of code

    // Load tinymce.js when running from /src, else load wp-tinymce.js.gz (production) or tinymce.min.js (SCRIPT_DEBUG)
    $mce_suffix = false !== strpos( get_bloginfo( 'version' ), '-src' ) ? '' : '.min';

loads tinymce.js only of we're using the src version of wordpress, otherwise it'll load either tinymce.min.js or wp-tinymce.js.gzip, depending on WP_DEBUG.
This means that WP_DEBUG will let me access only a minifed (or uglifyed) version of tinymce in normal (production) environment, which is not very useful for people like me who lack deep JS knowledge (actually I need testing also in production situations).
That's all.
In any case, I managed to resolve my issue by other means, therefor it is not that important. Thank you again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Build Tooling Issues or PRs related to build tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants