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

WYSIWYG editor doesn't open on product admin page #2656

Closed
hansgv opened this issue Oct 13, 2022 · 16 comments · Fixed by #2661
Closed

WYSIWYG editor doesn't open on product admin page #2656

hansgv opened this issue Oct 13, 2022 · 16 comments · Fixed by #2661
Labels
3rd-party Related to 3rd-party code or issues with customization backwards compatibility Might affect backwards compatibility for some users bug unconfirmed

Comments

@hansgv
Copy link

hansgv commented Oct 13, 2022

Under the admin UI's Catalog > Manage Products > Edit page, the WYSIWYG Editor for the Description or Short Description fields on the General tab doesn't open. Instead I see a series of errors in my browser console (not sure which one's are related to this specifically)

SyntaxError: Unexpected token ';' (this is from a javascript snippet where var LOADING_TIMEOUT = ;)
ReferenceError: Can't find variable: BLANK_IMG (this is from a javascript snippet where Ext.BLANK_IMAGE.URL = BLANK_IMG;)
Failed to load resource: the server responded with a status of 404 (Not Found) http://extjs.com/s.gif
Can't find variable FORM_KEY (I think this is the error that pops up when actually trying to open the editor)

I can reproduce this only after upgrading my Openmage 19.4.17 site to 19.4.18.

@sreichel
Copy link
Contributor

Cant reproduce with 19.4.x-latest

@elidrissidev
Copy link
Member

I also cannot reproduce this using the tagged 19.4.18 release.

LOADING_TIMEOUT was introduced only recently in #2426, did you refresh the cache after the upgrade?

For the other variables, I can't see a reason why they won't exist...

Screen Shot 2022-10-14 at 9 17 49 AM

@addison74
Copy link
Contributor

I tried to reproduce the error in OM 19.4.18 cloned today from the repository, but without success. Below is a screenshot from the Backend. In Console there are no messages and two issues appear related to prototype.js and tiny.mce.js, but they are not related to the reported issue.

screenshot

After any upgrade the OpenMage cache must be cleaned, also the browser cache. In a test environment disable both caches.

@hansgv
Copy link
Author

hansgv commented Oct 14, 2022

@elidrissidev I did empty Magneto's cache as well as browser's.

What additional info can I provide to help debug this?

I upgraded my site by extracting the 19.4.18 tar package to my root directory. None of the errors appear pre-upgrade. Everything else seems to work es expected both pre and post upgrade.

@elidrissidev
Copy link
Member

elidrissidev commented Oct 15, 2022

Can you post the content of the first <script> tag in the <head> of the product edit page? it should look like this:

<script type="text/javascript">
    var BLANK_URL = 'http://magento.localhost/js/blank.html';
    var BLANK_IMG = 'http://magento.localhost/js/spacer.gif';
    var BASE_URL = 'http://magento.localhost/index.php/admin/index/index/key/7a18a1ef53f5ed89b706dd61538e420d/';
    var SKIN_URL = 'http://magento.localhost/skin/adminhtml/default/default/';
    var FORM_KEY = 'QPBwweNxDvA7KaXZ';
    var LOADING_TIMEOUT = 200;
</script>

All of the errors seem to be related to some of these variables missing.

Edit: also wanted to ask are these errors happening in other pages across the admin panel or only this one?

@hansgv
Copy link
Author

hansgv commented Oct 15, 2022

@elidrissidev

Looks like this:

    <script type="text/javascript">
        var BLANK_URL = 'https://mydomain.com/js/blank.html';
        var BLANK_IMG = 'https://https://mydomain.com/js/spacer.gif';
        var BASE_URL = 'https://mydomain.com/index.php/hallinta/index/index/key/613fe4ceec22a7df08f7305ae1d31357/';
        var SKIN_URL = 'https://mydomain.com/skin/adminhtml/default/openmage/';
        var FORM_KEY = 'm07aQdv3hHfaAJxq';
        var LOADING_TIMEOUT = ;
    </script>

I think the FORM_KEY error points to this method in loader.js.

Ajax.Request.addMethods({
    initialize: function($super, url, options){
        $super(options);
        this.transport = Ajax.getTransport();
        if (!url.match(new RegExp('[?&]isAjax=true',''))) {
            url = url.match(new RegExp('\\?',"g")) ? url + '&isAjax=true' : url + '?isAjax=true';
        }
        if (Object.isString(this.options.parameters)
            && this.options.parameters.indexOf('form_key=') == -1
        ) {
            this.options.parameters += '&' + Object.toQueryString({
                form_key: FORM_KEY
            });
        } else {
            if (!this.options.parameters) {
                this.options.parameters = {
                    form_key: FORM_KEY
                };
            }
            if (!this.options.parameters.form_key) {
                this.options.parameters.form_key = FORM_KEY;
            }
        }

The BLANK_IMG error points to this script:

   <script type="text/javascript">
    Ext.BLANK_IMAGE_URL = BLANK_IMG;
    Ext.UpdateManager.defaults.loadScripts = false;
    Ext.UpdateManager.defaults.disableCaching = true;
    </script>

@elidrissidev
Copy link
Member

I am able to reproduce your issue, but only if I make the method Mage_Adminhtml_Block_Page_Head::getLoadingTimeout() return an empty string or null.

Please check the app/code/core/Mage/Adminhtml/Block/Page/Head.php file and make sure the content was copied correctly. You can also run the following snippet from a PHP file and see if it's gonna return something (should return a number):

<?php
require_once 'app/Mage.php';
Mage::app();
var_dump((new Mage_Adminhtml_Block_Page_Head)->getLoadingTimeout());

@hansgv
Copy link
Author

hansgv commented Oct 16, 2022

@elidrissidev It returns an int(200). My app/code/core/Mage/Adminhtml/Block/Page/Head.php file content matches with what's in the release package.

@sreichel
Copy link
Contributor

Is there any rewrite for Mage_Adminhtml_Block_Page_Head?

@hansgv
Copy link
Author

hansgv commented Oct 16, 2022

@sreichel I don't understand your question. Can you elaborate?

@sreichel
Copy link
Contributor

Can you please add var_dump(get_class($this)) to app/design/adminhtml/default/default/template/page/head.phtml to verify its not rewritten?

@elidrissidev
Copy link
Member

@hansgv Any update about this? As @sreichel mentioned, you might have an extension installed that overrides that class in which case you'll need to either copy it there or make it inherit from the core Mage/Adminhtml/Block/Page/Head.php.

@hansgv
Copy link
Author

hansgv commented Oct 18, 2022

@sreichel @elidrissidev Where in app/design/adminhtml/default/default/template/page/head.phtml should I add var_dump(get_class($this))? I tried adding it to the bottom but that doesn't seem right.

Nevermind the above, I figured it out.

I get a string(50) "Fooman_SpeedsterAdvanced_Block_Adminhtml_Page_Head". Disabling Fooman Speedster Advanced extension fixes the issue.

@elidrissidev
Copy link
Member

You may wanna keep that extension enabled if you're actually using it, and instead just copy getLoadingTimeout method from Mage/Adminhtml/Block/Page/Head.php to Fooman/SpeedsterAdvanced/Block/Adminhtml/Page/Head.php.

@sreichel sreichel added the 3rd-party Related to 3rd-party code or issues with customization label Oct 18, 2022
@kiatng
Copy link
Contributor

kiatng commented Oct 19, 2022

It'll be good to create this issue in https://github.com/fooman/speedsteradvanced

@sreichel
Copy link
Contributor

It'll be good to create this issue in https://github.com/fooman/speedsteradvanced

Just wait a minute .... ;)

@sreichel sreichel added the backwards compatibility Might affect backwards compatibility for some users label Oct 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3rd-party Related to 3rd-party code or issues with customization backwards compatibility Might affect backwards compatibility for some users bug unconfirmed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants