Closed (duplicate)
Project:
Bootstrap
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 Mar 2015 at 23:25 UTC
Updated:
1 Aug 2015 at 10:56 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
markhalliwellYou're gonna have to give me a little more to go on than "it's not working". I haven't encountered this at all.
Comment #2
majdi commentedthe problem back even with the old version, one thing on devel settings if I keep "Rebuild the theme registry on every page load" the not showing at all
Comment #3
majdi commentedalso im getting this error
but this just another problem , i think its related to the theme setting page , its seems its not saved when you hit save
Comment #4
majdi commentedComment #5
markhalliwellThis sounds to me like it's actually an issue with a conflicting module or perhaps something weird going on in the sub-theme?
At first glance, my theory was that it was devel incorrectly clearing the cache (because all bootstrap's DB caches are prefixed with
theme_registry:bootstrap:and there was somehow a race condition going on. However, I have since enabled said setting and still cannot reproduce this exact issue nor the notices reported above.Comment #6
glynster commentedI updated to the latest dev and ran into an issue where the primary and secondary navigation was no longer being rendered. Did all the usual, cleared caches etc but to no avail. Buttons were not an issue for me. However all this said I have not inspected the latest dev code to see what the issue might be. I have one custom override which is adding the class of primary to the primary nav. I removed the override and the issue remained. The previous dev did not have this issue (March 13). I will make an effort tomorrow to see if this is an issue on my sub-theme, which means something changed in the latest dev. Just thought I would add a quick reply here in the hopes this might be a connected issue and a trigger to what the issue might be.
Comment #7
markhalliwell#3: While working on #2452641: Add new Glyphicons from 3.3.2, I finally saw a CSS notice. I fixed it here #2450757-17: Provide a more robust CDN solution.
Regarding the rest of the stuff not actually rendering... I honestly have not seen this whatsoever. Can either of you give me clear steps to reproduce (i.e. on which page, steps leading up to it, etc.).
It may be related to #2447947: Allow dynamic #process and #pre_render hooks for elements, which introduced a new caching layer for element info. I'll post a couple patches here shortly for y'all to test out to see if either one (or a combination of the two) fix this "issue" that seems to be rather elusive.
Comment #8
markhalliwellOk, try both of these patches separately and then together (if needed) to see if this helps any.
Comment #9
majdi commentedI apply both, so far it seems okay , i will update you later today
Comment #10
markhalliwellPlease only apply one at a time first, I need to know which one is actually causing this issue for y'all.
Comment #11
majdi commentedI found the problem , it has nothing to do with bootstrap , The problem is that im using APC with FastCGI, when i switch to CGI the problem disappear and everything working fine but the site slow :)
The problem has nothing also to do with APC, it seems drupal have problem with FastCGI, sometimes forms load with different ID and I think that what break the theme
Thanks for your help I really appreciate your fast response
Comment #12
markhalliwellAh, yes... I have run into some APC issues in the past like this before for sure. The easiest solution was to simply restart the apache/fpm-php services so it would recognize the changes to PHP code (which is supposed to happen automatically, but sometimes lags behind).
As far as the different form IDs, that sounds like a misconfiguration of APC? I ran across these two tid-bits, not sure if it really helps any though: https://www.drupal.org/node/1542626 and http://drupal.stackexchange.com/a/42129.
Regardless, dealing with server performance/configuration is definitely out-of-scope for this project (nor is it really my area of expertise) so marking issue appropriately.
Comment #13
glynster commentedOK dam neither patch worked for me. Mine is not server relates that I can see. Yes I am using FCGI and have memcache however those are all restarted after the upgrade and caches cleared. Why just the main navigation for me! I am using the standard hook call from the page.tpl.php. Did something change there?
Comment #14
markhalliwell@glynster I would recommend using Xdebug to step through and see what exactly is happening and why they're not getting rendered. That's really the only solution I have to offer unfortunately.
Comment #15
glynster commentedOK good news.
Had a chance to review the issue. The latest release turns on CDN by default. On further review when I save my navigation comes back as expected however the Appearance form renders the original default settings for CDN.
http://awesomescreenshot.com/0d34n264e8
All other theme settings are maintained.
Comment #16
markhalliwellThe CDN has always been enabled by default... it was just saved as the theme setting
bootstrap_cdn. What was this setting before? It shouldn't add any CDN assets if it cannot find a version to enable (i.e. disabling this before mean setting bootstrap_cnd= '').Fixed that here #2450757-18: Provide a more robust CDN solution.
Comment #17
glynster commentedYes the latest dev pull works. CDN ui settings are now saved!
Comment #18
markhalliwellI have fixed the deprecated settings so they are correctly reflected in #2450757-19: Provide a more robust CDN solution.
FYI, I am linking recent comments/commits (in the last hour or so, after the new CDN feature went in).
I have also updated the change record to clearly identify how these settings are automatically converted:
https://www.drupal.org/node/2452617
Comment #19
glynster commentedAwesome you are doing a great job with this project!
Comment #20
majdi commentedThanks markcarver you really doing great job in this project
for the apc, my settings where fine , and i find out the problem source, its from APC module, when I disable it everything run fine under fpm-php, and site run very fast
Thanks for your help and the links you post are really good and thats info help me much
Thanks again :)
Comment #21
majdi commentedHello again,
I think the problem has nothing to do with APC cache, Right now Im having same problem in another site , The problem happen exactly if the site caching is on and during cache cleaning if any user done request for any page contain form the field will not render properly.
One thing I found which the help text under each field, bootstrap theme override that with help-block class and this happen when the form render properly, so while clearing the cache, if someone made request for the page that contain a form, you will not see the help text under class "help-block", you will find the class name is "description" which is the default drupal class.
So somehow the bootstrap module not override the form elements
Any idea how to solve that ?
Thanks in advance
Comment #22
markhalliwellI have not been able to encounter what exactly is being described here. Even if you cannot step through with xdebug, just let me know very clear steps on how to reproduce this issue (with a clean install of Drupal and Bootstrap... and if there is a conflicting module) , then I can step through myself. Otherwise, I cannot really help. Sorry.
Comment #23
markhalliwellNote: That wasn't an invitation to send me login credentials to an existing site, sorry. I just need basic steps to reproduce using clean installs (e.g. to see where the bug, if any, is in Bootstrap itself).
However that being said (and from the email sent, with screenshots), it appears that it may be possible that this is related to #2156371: Fatal error: Call to undefined function _bootstrap_process_element()?
Comment #24
majdi commentedHello
Sorry i thought you would like to check it by your self.
I follow with the ticket you point to and absolutely it contain the solution for my problem !
both of site works fine if im using bootstrap as admin and site theme
if im using Garland for admin theme the problem occur.
in one site increase max_input_vars solve the problem and I could not produce it again even if im using different theme for admin area
In the other site increasing max_input_vars did not solve the problem
I add this to one of my hook_init in custom module
the problem solve partially, so during clearing the cache if someone request page the result will be not themed properly, but after clearing cache finish , if i just reload the page everythings show fine, so this lead me to hook_cron and add the include in it
after that everything runs fine if i request the page during clean cache or not.
I know this is dirty fix but at least its working now 100%
Thanks again for your help
Comment #25
markhalliwellThat is very dirty indeed.... :(
As I have stated in that linked issue, the real solution is in patching core: #2448843-34: [regression] Themes unable to implement hook_element_info_alter() (patch).
Regardless, marking as a dup.