Hi all,
Well as the title says, input formats breaks the admin theme. The admin theme is unusable and the default admin theme becomes the frontend theme.
I'm using Rubik 6.x-3.0-beta1.
Note that the following warning happens when trying to create a feature : "warning: htmlspecialchars() expects parameter 1 to be string, object given in path\includes\bootstrap.inc on line 857."
Input Formats entry is displayed in Features' components, but clicking on it shows the right number of input formats but not the description next to it (blank). Selecting the checkboxes gives the expecting results, that is to say adding the input formats to the feature.
Disabling input formats does restore the rubik theme, enabling it does break the admin theme again.
Configuration:
PHP 5.3
Drupal 6.19
Ctools 6.x-1.7
Exportables 6.x-2.0-beta1
Strongarm 6.x-2.0
Features 6.x-1.0
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | admin-theme.patch | 600 bytes | bleen |
| #9 | input_formats.txt | 3.15 KB | blouhwtf |
Comments
Comment #1
lucascaro commentedwow... i was just going to report the same issue...
Comment #2
dagmarHi, thanks for reporting this.
I saw this too a few weeks ago. It seems to be a problem with Strongarm and the 'admin_theme' variable.
Debugging a bit of code, I found the raise of the problem in the wysiwyg_filter module. Last development version of wysiwyg_filter and this patch: #887532: Follow up: Input formats integration should fix the problem (at least it worked in my case).
However, if you are not using wysiwyg_filter, I would be nice to know which filter modules are you using on your sites, maybe they have to be patched too.
Comment #3
lucascaro commentedIn my case it's probably the wysiwyg module, i'll check, thanks.
Comment #4
lucascaro commentedI've tried the last dev of wysiwyg_filter and the patch, but I'm still getting the problem. In my case, every time i clear the cache, the admin theme gets ignored and the site shows the default theme for the next 1 or 2 requests (maybe a different issue?).
Comment #5
dagmarYou have to rebuild the feature with the patch applied.
Check if your feature have the item 'wysiwyg_filter_valid_elements_parsed' => array(... ) inside
If not, there is your problem.
Comment #6
blouhwtf commentedJust a quick update :
- updating to beta6 didn't solve the problem
- disabling all my filters : bbcode, markdown, php filter, html purifier, wysiwyg image upload (uses a filter as well)
- disabling better formats
None of that helps.
I am not using wysiwyg_filter module btw.
I'll try to dig into the code and debugging, see where it might be wrong.
Comment #7
dagmarHi:
I really want to fix this problem, however, I cannot replicate anymore. It would help if you provide the 'export' of your input format and attach it here.
Thanks
Comment #8
blouhwtf commentedOk, i went into some debugging and i really feel it is a cache problem.
With everything disabled like said in my previous post, it appears that it switches to the admin theme after some time without any configuration changes and whenever i clear all cache, it goes back to frontend theme. I can't find a logic in that yet though..
Comment #9
blouhwtf commentedExport of the input filters via bulk export attached
Comment #10
dagmarComment #11
lelizondo commentedI'm also having this problem. I'm not using the wysiwyg_filter module.
Edit: This module is also breaking context_reaction_theme module
Comment #12
lucascaro commentedThis is what happens in my site: every time the menu is rebuilt or I flush the cache (even clearing the cached css/js), the administration theme goes back to the front theme for the next one or two page refreshes.
Note that this doesn't happen when I clear the theme registry.
Not entirely sure but think the problem is with imported input formats like the following:
Comment #13
bleen commentedsubscribing
Comment #14
vordude commentedSubscribing And a +1 for the breakage.
Not yet even using the module, just installed it and my administration theme went away.
And I have the admin_theme variable already strongarmed, hmm.
Comment #15
xtfer commentedSubscribing. We have wysiwyg installed, but now wysiwyg_filter and see this problem on almost every page load.
Comment #16
bleen commentedWe are still seeing this error:
wysiwyg = installed
wysiwyg_filter = not installed
htmlpurifier = installed
admin theme = rubik
Comment #17
bleen commentedmore data: with this module enabled, the theme_init() function fires off BEFORE system_init() ... this is the cause of the admin theme breaking.
It seems that the strongarm module purposely gives itself a very negative weight in the system table and so its hook_init gets called *before* system_init(). Normally this isnt a problem, but somewhere in inputformats strongarm is being used in a way such that some value is buried inside a t(). This call to t() calles theme() which in turn calls theme_init().
I *think* this may be a core bug (theme_init() should check for admin theme)
Stil investigating...
Comment #18
bleen commentedfound the related bug report: #219910: Calling theme function from hook_init() interferes with administration theme
Comment #19
bleen commentedthe attached patch is a bandaid solution. It works (in a non-destructive way) by calling system_init() from within strongarm_init(). This is not an ideal solution, but it works and wont break anything. It doesnt make sense to open an issue for strongarm because the real problem is in core.
BLAAAAAAARGG!
Comment #20
nicholas.alipaz commentedbleen18, if your patch is against strongarm it should be posted against their issue queue. Just saying. But you did say it is a bandaid, so maybe you don't intend on them ever "fixing" the issue within strongarm, and rather there should be a better solution.
Comment #21
bleen commentednicholas.alipaz: The patch in #19 is not something I would expect the strongarm maintainers to consider including. It isn't really "correct" ... I do hope there is a better fix out there, but in the mean time I wanted to offer those stricken by this issue have a workable fix.
Comment #22
nicholas.alipaz commentedThanks for the clarification bleen18. I hope it gets fixed. This and the need to use wysiwyg filter for input formats has made me resolve to uninstall the input formats module from my features. I will keep following the queue in hopes that I can eventually place input formats in code. Otherwise I will just strongarm wysiwyg filter and leave input formats alone if the module never gets more stable.
Comment #23
liza commentednot sure if i should open a separate issue thread, but this isnt just an issue with the ADMIN THEME. input formats killed PAGE THEME in my case. so the problem must be with the theme switching function.
Comment #24
hixster commentedsubscribing- just spend a week developing a fully working WYSIWYG feature which we've just rolled out and now are experiencing lots of theme problems.
templates aren't being read unless flushing the cache.
Has this been posted over in the strongarm issue queue??? I can confirm that the patch fixed my issue
Comment #25
lucascaro commented"bandaid" patch #19 applied and seems to work. Thanks.
Issue #219910 has been there since 2008 so I wouldn't assume this is going to get fixed soon.
Also this comment: http://drupal.org/node/219910#comment-4559682 seems that coul help to solve this in a more ellegant way:
PS: There is no issue filled in Strongarm. should I move this issue over there ?
Cheers.
Comment #26
bleen commentedre #25... I refer you to #21. This really isn't an issue with strongarm, its a problem with core