You can modify what toolbar buttons show up in each platform (Desktop, Tablet, Phone). As an example, I added the font color option to the "Phone" toolbar and took a screenshot of how it looks on my phone. I changed the color to blue by tapping on the newly-added button:
If I delete all pages in the Pages app, an unfriendly error shows up on the home page: If I add a new page, the page is not automatically set as default which will cause the unfriendly error to continue to display. Marking a page as the default page corrects the issue.
When I want to add a "Page Builder" page to the Pages app, I get an informational message that says "You can edit this page's content by visiting the page." The "page" word is trying to link to the page, but it hasn't been created yet.
Unfortunately, I am not able to find an answer on that. URL rewriting attempts to direct forums.domain.com to a physical forums folder (which doesn't exist). It is worth mentioning that I am running on an IIS8.5 box.. not sure if this would be easier on a Linux/Apache box. Someone from IPS might have a better answer than me.
Here's what I set up: https://www.sinisterorigins.com/ On that site, the "Pages" app is loading by default (I moved my IPS4 installation to the root folder). When I click on "Forums" at the top, I am brought to https://www.sinisterorigins.com/forums/ , which loads the forums app. This matches the behavior of the site you mentioned (prideofnottingham.co.uk). You have to have "Friendly URLs" turned on to get this behavior to work correctly.
You can turn off the board wrapper in your pages app so that it's not included when you load domain.com. This gives you full control over how it looks... it doesn't have to look anything like the forum skin.
You can easily accomplish this by doing the following: Install (or move) your IPS4 installation to the root directory In AdminCP, under System > Site Features > Applications, click the Star next to "Pages" to set it as the default app Done! Your forums will still work under http://www.site.com/forums (because forums is no longer default) and your root domain will automatically show the pages app.
It's also quite a competitive market. A competitor can release a new major version of their software (and then subsequently release 33 betas... but whatever), so in order to keep people interested in IPS products, IPS releases a few details on the next version. Is it a bit early? It could be. But a major x.0 release takes a lot more time than a 3.x or 4.x release. It also appears that this suite is going through one of the biggest evolutions, ever (at least from my point-of-view).
I think it also has to do with IPS Staff getting excited about the new version as it evolves. I imagine they are just as excited to push the next version out as you or I will be when we get our hands on it. :smile:
I don't, actually. I had a grand vision of creating a truly unique design (you wouldn't have been able to tell that IP.Content ran it unless you knew exactly where to look) and databases were going to play an incredibly important role.
I just have so many bumps in the road that I can see ahead of me that I'm demoralized to even try it. How do I relate databases? If I do relate two databases, how can I display joined data between the two? Is it SQL code with PHP that gets me there, or does IP.Content automate some of that for me? I can't answer these questions right now because I can't find the answers in documentation anywhere.
I'm very well aware that IP.Content is not a glorified portal. I probably understand better than most people the power that is built into IP.Content. In terms of cost/benefit, it really can't be beat.
BUT, if I can't find documentation on how to relate databases together so that I can show joined records on one page and create a truly harmonious link between different databases, then what can I do? It takes me weeks to do in IP.Content what I turned around in 3 days in some of the other systems. Not because IP.Content is too complicated, but because I just can't find an example of HOW to do certain things and then build on that example.
As I said in an earier post, none of the systems I mentioned intergrate with Invision Board Products as well as IP.Content does. Most of them can do databases, they are simply named differently. And I don't miss the data part. I am an advanced website and SQL developer and have written queries that are literally hundreds and hundreds of lines long. The data aspect and the power built into the database tool is not lost on me.
I know for a fact that Sitefinity does implement this (in Sitefinity they are called Modules, and advanced workflows can be layered onto both the standard and custom modules. Sitefinity refers to blocks as "widgets"), and it's actually an implementation that's just as good as IP.Content, and because they provide videos, KB aritlcles, and very-detailed and well-structured documentation, I have been able to extend the capabilties of Sitefinity's modules far more than IP.Content's databases.
Those are pretty specific, but those are great examples of KB articles that provide a proven, working example.
In a framework, examples are everything. I should be able to google search "IP.Content database relationships" and I should get at least one example of a database relationship in action, either directly in the documentation itself, or in a KB article
An example would be Movies DB + Video Games DB.
Now, me being the webmaster behind SuperAwesomeMoutainBikes.com probably wouldn't want to create a MoviesDB and a VideoGamesDB, but I could re-purpse the code example into my two databases for MoutainBikes and BestMountainsToRideUp.
All I'm doing is re-purposing an example of a built-in feature.
So, you flesh out the documentation in the format I provided and create KB articles with examples like the one above, and you can then officially say you provided enough information for someone to get started. It can then be up to me to deep-dive into that stuff and ask the community/IPB if I can't figure out something.
There are dozens of other CMS systems that solve many of the problems IP.Content is trying to solve. I was looking at IP.Content because of its incredibly tight integration with IP.Board.
Many others can do what IP.Content can do, sans-forum integration. Off the top of my head:
Orchard Project (Requires Windows Server)
Joomla (PHP-Based, Open Source, Free)
Drupal (PHP-Based, Open Source, Free)
WordPress (PHP-Based, Open Source, Free)
Sitefinity (.NET Based, Commercial, Free Community Edition, otherwise $$$)
DotNetNuke Professional (.NET Based, Commercial, Free Community Edition, otherwise $$)
Umbraco (Not sure of backend type, Free basic edition, a la carte options $$$)
I'm currently evaluating IP.Content and Sitefinity CE.
All of IP.Content's features can be done on other platforms, the system isn't unique.
The link you supplied me with fixed ratings and many other things that weren't working on my web page, but it was apparently not enough to fix the error "ipb.textEditor is undefined". I still cannot find documentation on that error anywhere and have no idea what I'm missing in my code.
IP.Content isn't a basic product like Gallery or Downloads, therefore people need to rely on documentation more than other IPS products.
That's not what documentation is for. Documentation is there to document features of a product and their behavior. Overly-specific questions can be answered by the community or IPS via support.
In no way would I expect IPS to supply answers to all questions in documentation. What I expect is answers to the "Framework Questions". The documentation now is a complete mess because its very disorganized and very incomplete.
Here's what the "Add Page" document tells me:
That's it. It doesn't explain the features that are part of the three-step wizard, or what I'm even doing in "Pages" for that matter other than "Pages will contain your content".
That is an example of awful documentation.
When I look at documentation for other (non-IPS) products, I'm usually greeted with a nicely structured menu that I can either search or drill into by topic, feature, option, etc. to find the answer.
IP.Content's documentation is broken up into three or four different sections, and you can only search each one one-at-a-time. This is unintuitive, and there is no structure beyond one-level categories, either.
Here's what good documentation should look like for IP.Content. Let's pretend the menu below is what I'm greeted with and I'm currently browsing the "Add Page" document.
That isn't my point, that was an example. And to answer your question, there are dozens of other pieces of software, both free and commercial, that have much better documentation than IP.Content.
IP.Content is supposed to be a framework to allow you to build out an entire website. Something as important as that should be well-documented. There should be a place where I can find 90% of my answers, and the last 10% (usually the very-obscure problems) would be helped out by IPS support or the community.
The documentation doesn't have to tell me HOW to build my site, I realize that's my problem. But I should be able to find an up-to-date article on what I'm supposed to include in the header to allow all of the built-in features of IP.Content (adding/editing records, etc.) to continue to work without the wrapper. It's just good development practice.
It frustrates me because I know a lot of people are shying away from IP.Content because of its general lack of ease-of-use. You basically have to be a PHP developer with at least an intermediate understanding of both PHP and IP.Core/IP.Board's framework to do anything advanced with IP.Content.
That's not entirely correct. The software gives me the option to remove the wrapper from the page. It simply makes sense that they document what needs to be manually included again so that IP.Content's built-in features continue to work as designed.
I'm well aware that everything else related to design and structure is up to me.