Hello all,
Wasn't sure whether to post this here or in the Open Atrium project's issue queue; it's either directly related to the navbar module, or to Open Atrium's theme, or their inclusion of Bootstrap... but I don't know which.
Using:
- Open Atrium 7.x-2.25
- Navbar 7.x-1.0-alpha10+8-dev
- Open Atrium Radix 7.x-3.5 (default theme)
- Libraries is enabled
- Backbone (1.0.0)
- Underscore (1.5.2)
At desktop-width the navbar works fine. Icons, drop-downs, navigation menu items, search bar, etc.; all present. However, on tablet (portrait) and mobile devices (either orientation), the navbar simply becomes a black bar. What should happen is that, after a certain point, the navbar switches to one with only a few icons that toggle full-width drop-down menus... but that just isn't happening.
This started happening after updating the Open Atrium distribution from 7.x-2.23 to 7.x-2.24, which I had some other problems with (99% of which have been resolved), and has persisted through another, clean update from 7.x-2.24 to 7.x-2.25.
Screenshot of empty navbar attached.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | OA_missing_mobile_toolbar.jpg | 25.97 KB | denisev |
| intranet-navbar.png | 38.83 KB | kdmcguire |
Comments
Comment #1
kdmcguire commentedI've not received any response from the Mobile Friendly Navigation Toolbar issue queue, and this is quite an urgent issue (for us).
If it's less appropriate here please feel free to move it back, but I thought there's a good chance that this issue could be more closely related to Open Atrium and its customisations than to the navbar module itself.
Comment #2
kdmcguire commentedAnother issue, probably related: the admin menu, when opened, does not open over the top of the current page content. Instead, the page content is moved to the right.
Comment #3
mpotter commentedI cannot reproduce this on any of our sites here or on a fresh Pantheon install. Sounds like there is something else on your site causing this. You might also check your console for any javascript errors that might be causing this.
Comment #4
kdmcguire commentedTwo console errors that might be relevant:
The Colorbox library is installed in /profiles/openatrium/libraries/ and the underscore-min.map file is located in /profiles/openatrium/libraries/underscore/
Comment #5
mpotter commentedThe colorbox message isn't an actual javascript error and is an issue with the colorbox module...Works fine even with that message.
The Underscore library is a bigger issue. Try copying your /profiles/openatrium/libraries into your sites/all/libraries folder. That's a normal part of our install here because not all modules know how to find libraries in the profile directory.
Comment #6
kdmcguire commentedCopied /profiles/openatrium/libraries to sites/all/libraries, set owner/group to admin:www-data (like the other directories), but still no luck. I also tried putting underscore-min.map into sites/default/files/js, where it's apparently being looked for, but that also had no effect.
Comment #7
kdmcguire commentedI've also just tried uploading modernizr v2.7.1 (with the pre-built min.js file) to both libraries directories as it was not present but is recommended on the navbar project page. Still no change.
Comment #8
kdmcguire commentedLooking at this related question on stackoverflow and this even more relevant drupal.org issue, it seems that .map files are only requested when Chrome DevTools is opened. This particular 404 error would not affect a regular user at all. Disabling Javascript source maps in DevTools's settings prevents this error from appearing in the console log, and the page loads exactly the same.
So there's no evidence that underscore is not loading correctly, or that it's the cause of this issue.
FYI, we are using APC and Memcache - I'm not sure how to clear those, but I'll be looking into that next in case #5 should have fixed this.
Comment #9
mpotter commentedIf you navigate to an actual Space landing page instead of the Module admin page does it work? Can you inspect the HTML markup and see if the toolbar elements are on the page? Is the oa_toolbar module enabled?
APC won't have any effect on this and I doubt it's a Memcache issue. It sounds more like something isn't enabled.
(I'd also still copy the libraries to /sites/all/libraries if you haven't since there are definitely other issues that will require this)
Comment #10
kdmcguire commentedOur site has this:
The fresh site has this:
Comment #11
mpotter commentedAfter upgrading, did you follow the procedure and revert your features? Specifically, did you revert the oa_layouts feature?
The way OA determines which button to collapse each toolbar widget into is via the css classes set for the widget. So if you go into the Toolbar mini-panel and go to the CSS Properties of the Search widget, for example, you should see the css classes: "search-mobile-menu pull-right" which causes it to be collapsed into the search-mobile-menu.
Comment #12
kdmcguire commentedI reverted the oa_layouts feature last night, remade my changes to the footer (haven't yet mastered features), but that too had no effect. Having just checked, I can confirm that the Search widget does have "search-mobile-menu pull-right" in its CSS Properties.
The overridden features are:
Comment #13
mpotter commentedIf the search widget has the css property but isn't being displayed in the mobile button, then that means the script.js javascript in the oa_radix theme is not being executed. There is a function there called setMenu() that moves the widgets to their mobile buttons.
Comment #14
kdmcguire commentedI've checked my scripts.js file vs the working Pantheon site's script.js file, and they're identical. File permissions are the same, too. How can I find out why it's not being executed?
(Thank you for helping with this, by the way!)
Comment #15
mpotter commentedYou'll need to add some console.log statements to the script.js to try and debug why it's not getting to the setMenu function. I've probably reached the end to how much I can help with support on this since it's a site-specific problem and not reproduceable here.
Comment #16
kdmcguire commentedI asked our contracted dev to look into it. He's not had much experience with OA, but says that whilst script.js expects to find elements with the class "navbar-toggle", they do not exist in our site's HTML. They should be created by the template profiles/openatrium/modules/apps/oa_toolbar/oa-navigation.tpl.php, but he's not sure what's stopping that from working. I've checked our .../oa-navigation.tpl.php against the fresh Pantheon site's, and they're identical.
I'm going to keep trying to find a fix for this, but if you can think of anything else to try it'd be greatly appreciated!
Comment #17
mpotter commentedYou *did* delete your old files when you updated to v2.25, right? Make sure you don't still have the old toolbar in the profiles/openatrium/modules/oa_core/modules/oa_navigation directory, or in your sites/all/modules area. Otherwise it might be loading some older tpl somewhere and not actually using the newer oa_toolbar.
Comment #18
kdmcguire commentedI did!
Like https://github.com/phase2/openatrium-drops-7/tree/master/profiles/openatrium/modules, at profiles/openatrium/modules/ we have /apps, /contrib, and /panopoly directories. In /profiles/openatrium/modules/contrib/oa_core/modules, there's no oa_navigation directory. (Though, there is still a /navbar directory in /profiles/openatrium/modules/contrib)
In /profiles/openatrium/modules/apps there's an oa_toobar directory, but no oa_navigation.
Our /sites/all/modules/ directory contains apc, devel, memcache, and views_cache_bully.
Comment #19
denisev commentedThe same thing happens to the OA toolbar in 7.x-2.25 at my install.
Comment #20
joevagyok commentedI experience the same thing with fresh install, no need to do any action to reproduce it, except install OA :)
Comment #21
mpotter commentedFor those experiencing this problem in a fresh install, you'll need to post more about your environment. I cannot reproduce this on a fresh install here or on Pantheon.
Comment #22
kdmcguire commentedStatus report:
APC has been running for 6 days 3 hours. Currently caching 2568 entries (26.22 MB).
Go to the Advanced CSS/JS aggregation settings page and enable it.
You can run cron manually.
The timezone has been set to Europe/London. The first day of the week has been set to Monday. The medium date format type has been set to to December 6, 2014 - 8:36am. You may find it helpful to add new format types like Date, Time, Month, or Year, with appropriate formats, at Date and time settings.
Mail Comment requires that either the Notifications or Message notify submodules be enabled in order to function properly.
Mailhandler PHP IMAP requires that PHP's IMAP extension is enabled in order to function properly.
Mailhandler requires that PHP's iconv extension is enabled in order to function properly.
If the site is experiencing problems with permissions to content, you may have to rebuild the permissions cache. Rebuilding will remove all privileges to content and replace them with permissions based on the current modules and settings. Rebuilding may take some time if there is a lot of content or complex permission settings. After rebuilding has completed, content will automatically use the new permissions. Rebuild permissions
SimplePie library is required for Feeds SimplePie Parser.
SimpleXML PHP module is required for Feeds Syndication Parser.
Your server is capable of displaying file upload progress using APC RFC1867. Note that only one upload at a time is supported. It is recommended to use the PECL uploadprogress library if possible.
The jQuery imageAreaSelect plugin is installed at sites/all/libraries/jquery.imgareaselect
Comment #23
denisev commentedThe smaller mobile menu with the OA buttons starts to work for me after having activated the option "Menus" --> "Show main menu (if it has items)" under admin/openatrium/setting. Well, but only, if the menu has "items" assigned to it.
Comment #24
kdmcguire commentedYou've got to be kidding... Ha! It works!
Okay, so the new question is: why does the mobile toolbar use a different menu than the breadcrumb toolbar? There are a handful of users on my site who should have access to one Space only, I don't want them to see the menu links for all of the other Spaces they can't access.
P.s. Nice work, Denisev :)
Comment #25
kdmcguire commentedOkay, there's definitely a difference between my existing site and a fresh Pantheon site.
So, why does one site know to use the Spaces menu (despite allegedly being told to show an empty 'Main menu'), whereas another site will actually only show that 'Main menu' or nothing at all?
Update: With a link in the 'Main menu', my site will use the mobile toolbar, and it will show the expected Spaces menu. However, it will only appear if it is allowed to display something in the 'header' region. Because I've turned off the banner, which is what's behind the 'Navigation' toggle on the Pantheon site, it is insisting on a link from the 'Main menu'. The problem is, putting a link in the 'Main menu' forces it to appear all of the time... which is an unwanted side-effect.
Comment #26
kdmcguire commentedI made a 1x1 transparent image to upload as the banner (position: above toolbar), which still leaves a grey bar above the regular toolbar at desktop width, but is a bit less obviously redundant than putting links in the main menu for the sake of it.
This is a bit of an odd requirement; we were quite happy with just having the toolbar at the top, but the mobile toolbar seems to necessitate either a banner image or links in the main menu.
Comment #27
mpotter commentedI'll take a look at this. Certainly the "out of the box" install has the Open Atrium logo in the header along with an empty main menu. So if people have removed the OA logo or turned off this header then that definitely causes a difference from a default install and might be a case that didn't get tested.
RE: #24: The toolbar and the main menu are different on purpose. The toolbar is automatically generated from spaces and sections and will always show all subspaces and all sections within a space that you have access to. The Main Menu is more of a traditional Drupal menu and can contain links to anything you want: so you can only show spaces and sections you want visible in the main menu no matter where on the site you are, or maybe you want to add links to direct content pages, such as About pages, etc. Those are things you can do with the Main Menu that you can't do with the Toolbar. The Toolbar is more of the "breadcrumb" navigation for the site, not the traditional main menu.
But neither of them will show links to spaces the user doesn't have access to. As with all Drupal menus, if you add a link to the Main Menu to a space the user doesn't have access to it won't appear in the menu for that user.
Comment #28
mpotter commentedBtw, confirmed that removing the main menu from the header removes all of the mobile buttons. Have added this to our bug list for the next release. Denisev++ for tracking this down!
Comment #29
Argus commentedThe original issue "Toolbar empty at lesser widths" is fixed in 2.26 right? Can we close this?
Comment #30
mpotter commentedNo, this is still an issue in the latest version. Renaming the issue to better reflect the problem.
Comment #31
katrien_w commentedSame problem here after update from OA 2.19 to 2.26.
At first load my site looks fine, except the fact that on the OA toolbar the home button and breadcrumbs minipanel are missing. Minipanels 'add content', 'favourite' and 'search' are showing fine.
As soon as I click away from the homepage, my page layout totally breaks. I get flat node content without any panelization. The site banner shows IN the toolbar without stretching, the main menu shows in the toolbar without layout. Further only the user badge shows in the toolbar. The admin navbar also shows abnormal behaviour (as in #2).
After clearing all cache, the same scenario repeats itself.
I followed all 'good practices' on updating OA2.
Mike, my site should go online next week. Should I revert to an earlier version, or are you close to a solution for this issue?
Comment #32
mpotter commentedYep, as I said in #30, it's a known issue. Should be fixed in the 2.30 release tomorrow. In fact, it's fixed in the latest -dev of oa_radix 3.x and oa_toolbar 2.x if you want to grab those, but probably better to wait for the full release in case there are other dependencies. I actually had to rewrite how the mobile toolbar was being done since it was previously too tied to the banners.
I highly recommend updating your site to 2.30 when it comes out. There are tons of new stuff and bug fixes. This is our big quarterly feature update so really worth doing if you can before your site goes online.
Comment #33
mpotter commentedActually, closing this since fixed in -dev
Comment #34
katrien_w commentedNice! Can't wait for the new release tomorrow, thanks!