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?

Hi Gary,
when you create pages in Pages to hold the databases, or just act as pages, you can set the Theme for each page. You can also create page wrappers if you want, but there is just one menu, unfortunately.

For future proofing, I would suggest having the two separate if the navigation can be an issue.

If you tell us a little more about the two projects you are working on, perhaps we can guide you better?

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;

}

6 minutes ago, Gary Lewis said:

So having Forum and Pages be separate sounds cleaner. Is that something Invision has to do?

Yes, but there is only one menu possible as far as I know, so this wouldn't resolve your problem with the need for different menus on different pages.

8 minutes ago, Cedric V said:

Yes, but there is only one menu possible as far as I know, so this wouldn't resolve your problem with the need for different menus on different pages.

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

11 minutes ago, Gary Lewis said:

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;

}

yes you can do this, and while a bit time-consuming to do initially, it should not be a problem to maintain if you plan the main navigation accordingly. Just be aware that if the CSS for some reason does not load, it will show the full navigation.

Technically, you could also have different use groups for the Forum and the Pages and that can be used to control who sees what. Not sure if that is feasible for you?

If you want to have Forums and Pages as separate sites, then you will need two licenses as far as i know.

4 minutes ago, Gary Lewis said:

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

Yes, I think so.

You can also see if there are any mods that allow you to have two different navigations. That can still cause issues in future upgrades though, so you are kind of in the same situation there,

5 minutes ago, Gary Lewis said:

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

Misunderstood. 🙂

But yes, two installs would require two licenses.

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?

I don't know if I have told you, but I built an app Community Items which could resolve your issue. You can add categories and sub categories, has a gallery and everything you need to basically easily create a resource database for your Ford documentation. If you want to try out without obligation, let me know.

https://administrata.net/files/file/44-community-items/

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?

4 minutes ago, Gary Lewis said:

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?

Community Items isn't limited to community-sourced content. It works just as well (and often better) for admin-curated, authoritative libraries like the one you've built.

Think of it less as a "user submission system" and more as a structured content hub for your documentation.

In your case, each Item could represent a specific Ford topic, system, or model area.
The Item becomes the entry point, and the actual documentation can be inserted in that item.

Community Items acts as:

• A structured card catalog

• A searchable, browsable index

• A central point for each topic

• A discussion + Q&A layer around your official docs

You control:

• What items exist

• Which categories they’re in

• Where each item links

• What each item contains of documentation

• What custom fields are shown

• Which forum the discussion goes to

For example:

"Ford System Overview"
Description: Short summary OR complete documentation
Link: Your existing Weebly documentation or additional sources once your Weebly documentation isn't needed.
Images: Screenshots or diagrams, or display them between documenation.
Q&A: Member questions about real-world issues
Discussion: Ongoing community conversation

It's very powerful for:

• Official documentation

• Knowledge bases

• Resource directories

• Reference libraries

• Curated guides

Thanks, Cedric. I'll check it out.

@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.

1 minute ago, Gary Lewis said:

@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.

Not at the moment, but feel free to send details and I'll look into it.

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?

I'll send you a PM.

Thanks

If it’s just text data, it can be imported directly into the Pages database using phpMyAdmin. I’ve done it a couple of times.

Steps:

1. Create a few test records and export them to know the table structure and what they save (like Unix timestamps, boolean values and so on).

2. Reformat the import data in an app like Excel to match the structure found in step 1.

3. Try to import just one or two entries from the new CSV and check for errors.

4. Do the full import.

Of course that only works if there are no image fields, database relationship fields or anything like that.

@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.