If any of those sites are in your signature links. 2 of them I saw used the Article system, the rest were portals. The latest version of IP.Content solves most of your skinning issues honestly. The article system by default uses the 'IPB Wrapper'. So as long as your forum is skinned, the rest of IP.Content will have that same wrapper, feel and colors. No more trying to combine two CSS scripts and not understanding which style/id is stepping on the other. They already stripped it out and made them compatible for you.
This isn't the support section. I would make the post in the support section next time. However most it most likely is either due to the cache. Do you have it set as 0 or a another number when you create the block? You shouldn't need to delete the block just edit the block that isn't showing and the cache will be updated.
It isn't something that I have had happen though on any of my sites. If it is still doing it. You've updated to the latest version of IP.Content and IP.Board then I would suggest submiting a ticket.
Tags for Articles and forums I'm not so much interested in. I'm sure it will and can happen but I don't see it happening soon. The reason things like Joomla and Wordpress needed tags over IP.Board was because their search engines sucks. It really only typically searches topics, titles and rarely body. Tagging was put in as a way to add an extra function for their search engines without them having to revamp them. It became more popular with social networking and has grown from there. When you compare IP.Boards search function though I've never had an issue finding something because it was vastly superior.
Now the IP.Gallery is where tagging is greatly needed. Images typically don't have a body of text to search, title that matches the image or the image fits in multiple categories. Until they revampe IP.Gallery though, then figure out how they want to implement tagging... then they'll probably see about applying that across all IP products at that point. If tagging happens though I really expect it to happen to IP.Gallery first, then can be worked in as a module, hook or block after that.
You could go into the skin for your forum and create a "if" function using:
<if test="IPS_APP_COMPONENT != 'ccs'">
The code you want to use for the footer instead.
Original footer code
When it is in IP.Content it will display your other footer code. When it is in the forums, it displays the normal forum footer.
This is the one comment I find funny. Sorry not specifically directing this at a single user, "just quoting the part about the documentation so people can jump right into it". This seems to be a constant theme of what people want. HOWEVER it is not what they are asking. NO ONE wants simple instructions that gets them working out of the box. The reason is because there hasn't been one person who has posted on this thread who uses IP.Content like any other same user.
Since IP.Content 2.x out of the box it works and functions as an article system. It even had a demo site. With IP 2.1 they changed the demo to use your IP.Board wrapper. Install. Start making articles, no configuration and it is initiative. It is that simple. Boom they can add 'Content'.
The problem is even though that is what people are asking for, it isn't what they want. Now they want instructions to use the database. Now they want instructions on how skin it. Now they want instructions on how to get X to display, instead of Y. How to create a 'custom' navigation bar, etc. These requests aren't about simply using the product, these requests are the result of wanting to use features of the product that the 'user' probably doesn't even have an idea how to incorporate it. They just see it, they want to use it. So they ask for direction and help.
People can not create 'generic' documentation. It already exists. They want more precise information. But the main issue is what 'User X' wants 'User Y' wants differently. Most of the questions about layout, design, that is just simple CSS and HTML and there are already documentation on that all over the web. The database is a bit more trickier and most users don't even use it.
IP.Content is not a CMS. It has the makings to become a CMS and has a good foundation to move beyond a CMS, however it is not a CMS. You have the ability to create dynamic content for your community with IP.Content. But most people 'ask for a generic template (which it has)' but they really want something more complex.
It has come a long way. Has the users help define the direction, it tends to point the direction that IP.Content goes. Like the recent addition of 'Widgets' and 'Demo' site using the IPB Wrapper instead of not.
However when it comes to the hours I spent making Joomla and Wordpress databases compatibility with IP.Board, member databases sync up only to have to redo it every update. I'm sorry it doesn't matter how many features they have. When it comes down to it most users don't realize they are using Joomla/Wordpress as a blog, post articles or various videos/text content. IP.Content does that already and I don't have to spend hours trying to sync up member databases.
I think the biggest issue, at least the issue I had with it, is that people are WAY over-thinking it. People are used to Wordpress, Joomla template editing, etc. Which those in my opinion half the time don't make sense. It took me hours to figure out how to skin Wordpress, annoying me that I had to go into a header file for half of it and into the footer for another. I preferred to have everything in one template where I could edit it.
IP.Content did that... sort of. Once I broke it down into little building blocks I got the idea of how it all fit together. I think the big problem is that there are 2-3 different ways to skin/customize IP.Content mainly IPB Wrapper and without. A lot of people in their mind have a finished product or layout in mind. They then need to decide which path to take and go with that. Frontpage is simply the template for the main front article view. Article view template is for when you 'view' an article. Page templates are typically individually, separate pages not part of the article system. Blocks are the modules that can fit into your templates. You include CSS like any other html page. Media Database is a different topic entirely. Most people will not use all of IP.Content and it really is multiple things but people try to push them together. You have an article system, very similar to a blog or wordpress system in itself. Then you have a database which can be used for other things, one example was Media. You don't need to do anything with the database for your articles but most try to dive right in instead of taking initial steps. I try to get the layout the way I want. Then I look at what content I can add after that. But that is just me.
It is about time they finally redid it. Hopefully it will have the missing things that I've been waiting for a long time for: RSS Feed, Image Tag Cloud to make it easier to search through hundreds of uploaded media.
Pages themselves once created, the content part would be considered similar to a post. Essentially create a flag in the user group for IP.Content, like with Gallery, to choose what they can edit, moderate, etc based on user group permissions.
My real issue with editing pages in the ACP is that I have to give everyone access to those pages. If I create a set of pages for the "Artists" of a community design pages they can edit content with. Then do another set for the "Writers" in the community". There is no way to stop one person from editing another persons pages. It's an all or nothing sort of deal.
I believe the initial set up for templates, blocks, and the initial page set up should be done through ACP. But once that is done, a user group should be able to edit the "content" only part of the page from the 'front-end' based on user group permissions. Which would mean treating folders similar to categories, so that a person could give editing permissions to one user group for one folder and yet permissions for another user group in another folder only.
Other gallery systems like Gallery, give the option to autocrop square thumbnails. So you can choose to use them or not. Then they crop a square around the center of the image. You can also select a different size crop than a square for example if you wanted all images to be 50x100 or 100x100. To handle the cases where some images crop blank space (which doesn't happen too often), they include a manual crop which then lets the user edit the crop selection and resave it.
It satisfies the people that want the option. It satisfies the people that don't want the option. It gives the clean uniform look that many users crave, but also lets them choose to do rectangles instead of squares (for panoramic crops). It also solves the issue of blank cropped images, letting them select a manual crop... as there are usually a lot less images needing to be recropped.
Looking good so far. I do notice that the tagging system that I heard hasn't made it in yet. What about RSS Feed? Is there an RSS Feed for the gallery images now, so users would be able to use something like "Cooliris"?
To most users most people will only see the "main webpage" as being done with CCS. The advantage of CCS is that you have the ability to seemingly integrate website attributes without having to fake it.
For example IPBeyond is currently all through IP.Content. That includes using databases for their articles and other parts. But most people probably won't be able to easily spot where IP.Content is being used "other than the main page".
Most people will just link their main page to show a integration of the site. There are typically more pages than just the main page, which you refer to as a portal page. I use it with one customer as a database for all their stories. Each story has their own page, the header, footer is wrapped up nicely to look integrated with the forum. Most of the activity is on the forum but it gives the website a "complete" feel. Unless you created your own "fake header/footer" to mirror IP.Boards and then put that in the beginning of every .htm/.php page you created then you couldn't create an integrated look. At least not without using frames, iframes, etc. You have a method to create just a content page, just information and not have to worry about header/footer every single time. It provides a fairly easier method to create for those that aren't HTML inclined, simply using BBCode as well. It would be nice to have a full page editor but in time.
I love with IPB 3.x I can set ACP permissions and allow some moderators access to member tools, without giving them full access to the ACP. This has allowed me to properly set up moderators and admins to help up, but also set up a security to where one person can't totally wipe out the site in a fit of rage.
I've done a lot with IP.Content. I've used various methods to integrate it with other site projects that I'm part of. I've done some extensive testing with another project I'm working on as well. It provides some simple, yet robust method to integrate all my side projects into one nice "community" package.
The major flaw I'm encountering currently is that I have no security control over who has access to the CCS pages. I can either not give them access or give them complete access, in which case they can access other CCS pages which effect other parts of the site.
As an example, I'm part of an artist community. They use a couple IP.Boards linked together to communicate, exchange ideals but also use some web comic tools in lieu of the gallery. The only flaw was that the community wasn't much of a group feel, every page was unique but no "uniform" that pulled everything together. With CCS we have been able to do that. So 'Artist A' can create his pages and site to be unique, but still have some "Wrapper" features that tie it to the main site and the community as a whole. 'Artist B' can also do the same thing, but at the same time he can delete, edit the pages set-up for 'Artist A'.
Now I'm not expecting anyone to purposely sabotage or delete someone's page(s). But honestly everyone is human and during certain times, can be prone to be angered. I'd prefer not to have the temptation there or create un-needed drama with other moderators. Granted I can grant none of them access to that part, but then that means I have to manage, do and update content for all of them... and well that is a pain.
Basically I would like to see some more ACP permissions set up for CCS. Set it up maybe similar to forums, so I can set certain member groups to have access to X, Y Folders but not A, B Folders.
Please in the next version of IP.Gallery finally give us RSS Feed for images. This will let users take advantage of a few other add-ons for Galleries that they will be able to utilize through with the RSS Feed like Cooliris, etc.
Not to mention having a feed to be able to see which images are new, etc would make it so much easier for larger galleries.