Gary Lewis

And I should have said I'd be happy if both menus stayed, but can live with just the one that we've drilled down into.

Well, I guess I didn't ask that correctly and confused everyone. But I've learned a lot and taken a different direction so want to restate the problem. We've quit trying to do this via CSS and are now trying to do it via menus. What we have is three top-level menu items: Forum as a sub-menu with other forum-related stuff under it, like an About page, Activities, and Browse Library as a sub-menu with other library-related stuff under it, like a different About page, the start of a database to serve as "card catalog" to tell people where to go About Bullnose Enthusiasts - a page with nothing under it. This works, but when we click on something in the dropdown below either Forum or Library both Forum and Library go away and all we are left with is About Bullnose Enthusiasts and an empty More. It seems like we are doing something incorrectly as we expected at least the menu section we are in, either Forum or Library, to show - if not both. Can anyone tell me what we are doing wrong? Please?

@opentype - Thanks! We will give that try. It'll just be a page title and URL. There will be three fields, with the 3rd being metadata, but I'll have to enter that later.

Thanks

We’re using a Pages database as a card catalog and need to seed a few hundred records from a CSV (Title, URL, & metadata). We don’t need a new content app — just a bulk importer. Is that something you’d consider building, and if so, what would be the ballpark cost?

@Cedric V Does your Community Items allow CSV file import into a database? As said, we have ~950 pages on Weebly and it would be nice if we didn't have to manually enter all that info manually.

Is it possible to import a CSV file into a database on V5? If we go with Pages we will have a hybrid environment for quite some time with both Pages and Weebly since we have ~950 pages on the latter. So we are considering building a "card catalog" that will list all the pages, regardless of where they reside, have some metadata so users can search, and a URL to get them to it. But it sure would help if we could import a file.

As you know, we’re working with a trial of Invision Community v5 Pages as we are considering bring a portion, if not all, of our huge Weebly website over. And are intentionally trying to separate navigation between Pages (reference/library content) and Forums (community content) so it looks like our forum is standalone from the "library" on Pages. On desktops we’ve successfully controlled menu visibility by app context (Pages vs Forums) using theme CSS. However, we’re seeing inconsistent behavior on mobile and tablet iOS devices, and before making architectural decisions I’d like to confirm what is and is not supported by the platform. What we’re observing • iPhone (Safari and Chrome): When viewing Pages content, the hamburger menu still shows forum-related items (Activity, Browse, About), even though those items are hidden via CSS elsewhere. • iPad (portrait and landscape): When viewing Pages content, the “More” menu appears but is empty. This is probably because the items that would normally populate “More” have been intentionally hidden via CSS; however, the responsive menu still renders the “More” container itself. We have not yet tested Android devices, so we are not assuming identical behavior there. Questions In Invision Community v5, are the mobile hamburger menu and tablet “More” menu rendered from the same theme/DOM layer as desktop navigation and therefore intended to be fully controllable via custom CSS? Or are the mobile and tablet navigation elements generated by responsive or device-specific logic that is not designed to be selectively modified or hidden via CSS on a per-app (Pages vs Forums) basis? Is it supported to hide or alter mobile and tablet navigation items based on app context using CSS alone? Is the behavior described above on iOS (persistent hamburger items; empty “More” menu after items are hidden) considered expected behavior or a known limitation of responsive navigation in v5? A clear explanation of what is and is not supported across desktop, tablet, and mobile would be very helpful, as this will determine whether we attempt to present Pages content as visually standalone on smaller devices or accept unified navigation there. Thanks for the clarification. Gary

Thanks, Cedric. I'll check it out.

No, I don't think you told me. I'm interested, but am not sure how it fits. Our documentation/libary isn't community-sourced. I've created the ~950 Weebly pages over the last 10 years, keeping them pretty much to Ford-sourced documentation. So the "card catalog" will determine whether the user is going to a document on Pages or one on Weebly, and that is something I'll set up. I've read what you have on the page, but it seems mostly targeted for community-sourced things. Right? Maybe I'm missing something?

Ok guys, thanks. Here's more background and then the plan to try this afternoon. I currently have an Invision forum and a huge documentation website on Weebly - both for Ford's 1980 - 86 light trucks. But the documentation site serves all owners of those trucks across all forums and Facebook pages, not just our forum on Invision. So we'd like it to stand alone - at least visually if not actually. We've come to realize that Weebly lacks tools that would help the documentation effort, like the database function which Pages has. But Pages doesn't have some things that Weebly does, like picture galleries. And no one has a migration tool to move a Weebly site. So we are looking at a hybrid, with some of the documentation on Pages and some on Weebly, and a database (we call it the card catalog) on Invision that sends the user to the right document, whether on Invision or Weebly. Over time we'll probably manually migrate some Weebly pages to Invision, and most new documentation will be done on Invision - save for picture galleries unless or until Invision has that capability. But the "separation" is the issue. As said, we got it working via CSS looking at navitem id, but that is fragile. So now we are looking at using the URL as it appears to be fairly straightforward and stable. Comments? Better ideas?

If we had a Forum instance and a Pages instance then their menus would be separate. But does that require separate licenses and cost?

Thanks, Jimi. @Cedric V suggested that we use CSS to hide menu items, and we've proven that concept via the code shown below. But, as you can see, the code relies on a stable menu as it calls for a specific menu item to be hidden, so that means we'd have to lay the menu out once and for all times or go back and edit the code. So having Forum and Pages be separate sounds cleaner. Is that something Invision has to do? /* ========================= NAV / MENU VISIBILITY ========================= */ /* BB (Pages + Databases): hide nav item 46 */ body[data-contentclass^="IPS\\cms\\"] [data-navitem-id="46"] { display: none !important; }

I have a forum on Invision and a very large reference library on another platform. The library serves a large audience beyond that of the forum, and I want to keep it at least appearing to be separate from the forum. However, I'm considering moving at least some of the library to Pages, and worry that having the two applications sharing a global header will tell everyone that they are really joined at the hip. One approach I've considered is to use conditional logic in the header to present different menus/headers depending on the application. But I worry that upgrades in Invision will break the logic in the future, and I'm not really able to make changes once someone else gets it working. And at 78 years old I'll need to pass this on to someone else some day, and doubt she or he can maintain it either. So, how sustainable would that approach be? Or are there other or better ideas to keep the two separate - at least in the view of the user?

Hey guys, just to let you know we've figured this out. In our trial of Pages V5 we've created a database for Ford's technical service bulletins, TSBs. The user can sort the database by applicable year and/or category, like body or electrical, and then see all the TSBs that apply. Click on any TSB and the code hands the URL of that TSB to the Adobe API and the TSB then opens on the page - quickly. The user can then search for anything in the TSB, use any bookmarks that have been added, or download the file itself. This is a really powerful tool for our documentation library which, by the way, is the place on the internet for Bullnose (1980 - 86) Ford trucks. (So much so that we are recognized by Ford.)