Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When clicking on the icon in tinymce to launch the img_assist browser it is spitting out a dead link.
The non-tinymce icon works fine but the button in tinymce doesn't.
After clicking on the icon it launches a popup to: index.php?q=img_assist/load/tinymce&textarea=edit-body&q
The &q at the end breaks the page and just loads instead of the module. I checked editor_plugin.js and on line 44 it has - file : Drupal.settings.basePath + 'index.php?q=img_assist/load/tinymce&textarea=' + ed.id,
I'm not sure why it's appending q= to the end of the URL. Thoughts?
Thanks
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | drupal.js-query-string.patch | 908 bytes | sun |
| #3 | drupal6.js-query-string-d6.patch | 923 bytes | sun |
| #2 | wysiwyg-HEAD.js-query-string.patch | 830 bytes | sun |
Comments
Comment #1
Stolzenhain CreditAttribution: Stolzenhain commentedI encountered exactly the same problem on this version, a last ?q= breaking the popup query link.
I also noted that a bad path is only generated through the TinyMCE button, but not the regular plugin link below the textarea.
All versions of WYSIWG API, TinyMCE and Image Assist are the currently recommended ones.
Comment #2
sunCommitted attached patch to all branches of Wysiwyg API.
Comment #3
sunAttached patch fixes the cause for this issue: Drupal core should not use 'q' as query string for page requisites.
Comment #4
sunAssigning proper tags.
Comment #5
Eric_A CreditAttribution: Eric_A commentedThe very recent #454992: JavaScript query string breaks $_GET['q'] is a duplicate of #320206: _drupal_flush_css_js: css_js_query_string should not be 'q', but Sun's patches actually made the test bots happy while Bengtan's for some reason did not.
We need this issue to be resolved as quickly as possible. @Bengtan: in the interest of this I'm proposing we all join forces in #454992.
Comment #6
bengtan CreditAttribution: bengtan commentedMoving here from #320206: _drupal_flush_css_js: css_js_query_string should not be 'q'.
One guess is that the tests changed in the meantime, around May 1st, which flagged a false negative for the patch proposed in #320206: _drupal_flush_css_js: css_js_query_string should not be 'q'. And the tests got fixed up recently, so now the patch passes all tests when in the guise of #454992: JavaScript query string breaks $_GET['q']. (The patches for both issues for 7.x are identical).
If you look at the test results for #320206: _drupal_flush_css_js: css_js_query_string should not be 'q', you will see that it passed when tested many times before May 1st.
I suspect, if someone can trigger the test system to try #320206: _drupal_flush_css_js: css_js_query_string should not be 'q' again, it may just pass successfully too.
Comment #7
sunThere is no way to replicate this issue in core. Some JavaScripts, such as client-side editors, are trying to auto-discover any possible query string of the current page to append it to the URLs they are generating. In case of TinyMCE, the editor scans for its own library script name in the HTML output and uses the discovered query string for any generated URLs in the editor. Thereby, if some editor plugin invokes a Drupal path, e.g. to output a modal dialog, the server gets two q's in the query string, and the last one wins.
Comment #8
sunWell. Simple patch, tests pass, and even another issue that implemented the very same fix. What else is needed for RTBC?
Comment #9
webchickI asked sun for a description of the issue since I was a bit lost as to why this patch was required. #7 helped a little, but several of the replies at #320206: _drupal_flush_css_js: css_js_query_string should not be 'q' did a very nice job of explaining the problem, which ultimately helped me to understand it. Thanks for that.
@bengtam: I noticed you were getting a bit frustrated in the other issue. Just as a bit of background, core committers tend to focus on the "reviewed and tested by community" queue, as a general rule (though we also review patches, too). The best way to get a patch core maintainer attention is to get it to RTBC, and the only way to do that (legitimately, without incurring negative karma by marking your own patch RTBC ;)) is to acquire some peer reviews. That can be a bit challenging sometimes, since there are many issues in the queue vying for attention, and not enough people reviewing them.
One really effective way to handle this is to engage in "patch review swaps" with other developers. These are mostly done on an ad-hoc basis in IRC with an informal, "Hey, could someone look at XXX? I'm happy to review something in return." You could also try reaching out individually to people via their contact forms who comment on your issue saying they can reproduce the problem, and help walk them through how to apply and review patches if they don't understand it. This way, we help grow the number of reviewers for future patches, you get your patch looked at and escalated so that it goes in, and everyone wins. :)
Committed to HEAD. Marking down to 6.x for consideration.
Comment #10
bengtan CreditAttribution: bengtan commentedThanks webchick. I'll know better for next time.
Eric_A was concerned that the automated test system rejected my patch from the other thread whilst accepting the patch from this thread, even though both are identical. I don't know whether he wants to follow this up or not, or spin off another issue to deal with it.
Comment #11
Gábor HojtsyCommitted to Drupal 6 too, thanks.