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.
Take a peek at http://drupal.org/node/409034
Comment #3 demonstrates the line causing the problem. No idea if this is fixable.
Comment | File | Size | Author |
---|---|---|---|
#5 | admin_theme-464738-5.patch | 1.39 KB | markus_petrux |
Comments
Comment #1
markus_petrux CreditAttribution: markus_petrux commentedhmm... it looks like
$custom_theme
is set by admin_menu depending on the path, but since the AJAX request comes from a different path, then that response doesn't take into account the different theme, and then... bang!I'll have to think of a reasonable way to fix this. Patches and ideas are welcome. :)
Comment #2
markus_petrux CreditAttribution: markus_petrux commentedOk, after thinking about different ways to approach this problem, I think it should be the admin_theme module that needs to deal with this particular situation.
Here's how it could be done:
1) When admin_theme module switches the theme by settings the variable
$custom_theme
, then it should store this fact in some kind of per session persistent storage. It could be$_SESSION
, or it could besetcookie()
. I guess$_SESSION
would be a safe choice and easier to implement. Probably, all user that are allowed to use the admin theme are registered users, so they already have a session.2) admin_theme could check
$_SESSION
to see if previous page request enabled the admin theme, and grant admin theme again if the current request is ajax.Please, test and let me know if it worked or not. Also, trasfering the issue to the admin_theme queue.
Comment #3
markus_petrux CreditAttribution: markus_petrux commentedBetter title. I think. :)
Comment #4
chriscohen CreditAttribution: chriscohen commentedCan you roll this as a patch against a specific Drupal version please? Subscribing - I'd like to know the outcome of this.
Comment #5
markus_petrux CreditAttribution: markus_petrux commentedOk, here's the patch. Its against the DRUPAL-6--1 branch of admin_menu module.
Comment #6
loze CreditAttribution: loze commentedApplied the patch, but It did not solve the issue.
Im getting the same results as without the patch.
Comment #7
markus_petrux CreditAttribution: markus_petrux commented@loze #6: "does not work" does not help much. What's your config and what is it that does not work?
Comment #8
loze CreditAttribution: loze commentedI have the same problem as the original issue linked to http://drupal.org/node/409034
I have a view, with editable fields set up.
and an admin theme.
When the view loads the editable fields ajax, it grabs the front-end css and applies it to my admin theme.
I applied the patch, cleared my caches, and get the same results as w/o the patch. (no visible changes)
I am using a zen subtheme on the front-end
and basic for the admin theme.
d6
thanks.
Comment #9
markus_petrux CreditAttribution: markus_petrux commentedThis problem may also be related to #508536: play nice with $custom_theme, if those themes check for $custom_theme using isset(). Try to apply that patch, which is one-liner.
Another thing to try would to test with garland as front-end theme, and any other theme for the admin side. This would help isolate the problem.
Comment #10
loze CreditAttribution: loze commentedThanks markus
I have applied the patch #508536
And changed the font-end theme to garland and set the admin theme to push button.
And still get the same results.
With firebug i can see that all the css files of the front-end theme are being added to the page when the ajax request is completed.
Comment #11
markus_petrux CreditAttribution: markus_petrux commentedI'm lost on ideas. The patch in #5 works for me here.
hmm... well, we're using $_SESSION to tell the *next* request to use the admin theme if the previous one was using the admin theme. But this only affects the *next* request and if it is an AJAX request. If there's another request in the middle, or more than just one AJAX request, then the patch in #5 might not be enough.
So maybe this needs a bit more work... but I don't have time now. Ideas are welcome.
Comment #12
loze CreditAttribution: loze commentedThanks for your help.
I was looking over the patch in #5 and it appears to check if the request enables the admin theme.
My problem is that on the admin theme, im getting front-end styles after the ajax request.
Could it be that the patch should check in the opposite direction as well?
Comment #13
loze CreditAttribution: loze commentedIt looks like i was able to fix this by adding the following to admin_theme_init()
Im not sure if this screws anything else up, but it appears to work for me now.
thanks again.
Comment #14
yosh CreditAttribution: yosh commentedI have been having problems similar to those previously mentioned in this thread, especially with CCK fields and Panels that use AJAX/AHAH to load/reload certain parts of admin pages.
I came up with a relatively simple solution that does not require the use of
$_SESSION
as it is rather unreliable. For instance, if a user loads an admin page, then loads a regular page in another tab, and then loads the AJAX functionality in the admin tab it will fail because$_SESSION['admin_theme']
was reset in the regular tab.My patch relies on the HTTP headers
X-Requested-With
andReferer
, meaning that if those are not set correctly by the user agent it will not work. It has however been tested in a number of modern browsers that all apply these correctly.Basically if the HTTP headers are set it will use the path from
$_SERVER['HTTP_REFERER']
instead of $_GET['q'], thus pretending to be the requesting page itself and applying admin theme as necessary.I would like to hear your opinions on it and see if it needs further improvement.
Comment #15
mxhThis problem also occurs in D7. Still.
I'm marking this as major because the module causes other modules not to work properly.For example, Field UI and Display Suite: It's impossible to drag and drob fields in the manage display area.
And of course, views with a large amount of rows are not able to have editable fields, because the whole layout is broken when ajax_load comes in the game.
Greetings
Comment #16
mxhseems this will be fixed in the upcoming D7 release, see http://drupal.org/node/967166
Comment #17
mxhproblem is still there with D7.14.
Comment #18
Andrew Answer CreditAttribution: Andrew Answer commented.