Hey, welcome aboard!

We've been using concrete5 pretty much exclusively for over six years now and have used it for a whole range of different purposes - large organisation websites, shops, pdf generators, real-estate websites, directories, membership systems, competition management, all sort of things!

There is a long list of reasons why we use concrete5, but the main one is really that is allows for flexibility in a way that we've not found in other systems. Being able to take a page and split it up into columns with 'layouts', or being able to control pages and blocks with fine-grained permissions, or being able to use page attributes are all the things that add up to mean that we can solve problems in maintainable, non-hacky ways. We're also able to return to sites that are 5+ years old and continue working on them without headaches.

Going through the doco and following the in-built guides makes perfect sense as a place to start. There are many videos and guides available, but ultimately you'll find that concrete5 is really quite easy to pick up and follow. There is also a huge amount of information and answers within the forums, where simply googling for things can result in a very clear answer in a forum thread. If/when you do ask questions just remember to indicate what version of concrete5 you are using and be clear with what you are trying to do and what you have looked at so far. A really clear question with detail nearly always gets a quality answer.

I'd suggest just rolling out a test site on a local webserver and playing around with creating a few skeleton sites, looking at how you might make site structures, page lists and navigation.

The default theme for concrete5 is pretty flexible, and there are lots of things on the marketplace, but I'd emphasise that you should still see concrete5 primarily as a content management system, rather than a design tool. Yes you can take a theme and change colours and make lots of visual changes without touching a line of code, but I do think it's better to try and pick a theme that is pretty close to how how you'd like things to look, or if you have a very custom look in mind developing one of your own. Ultimately what you don't want to be doing is hand-styling individual blocks and pieces of content too often - the built in design tools are really handy but are perhaps better for exceptions, rather than the primary tools to style your site.

You also don't want to work with one theme and input a lot of content and then part-way through swap to a completely different theme. You _can_ do this, but you may find that some themes have extra areas that others don't include. All themes generally have a 'Main' area for content, but sidebars, headers and footers may be quite different, so focus on getting everything set up how you like with sample content, before committing to populating your site.

Once you are up and running you'd naturally want to explore the marketplace. The main advantage to the marketplace is that to get an add-on or theme published it does have to pass a bunch of tests and inspections from the 'peer review board'. This means that the quality of the code in the marketplace tends to be high, but also if something is truly broken you can seek refunds. There are add-ons in the marketplace that also allow you to create your own custom blocks as well - this can be very useful.

I know you've said you don't code, but I'd suggest not writing that off completely as something to look at down the track. Concrete5 has things like 'custom block templates', which give you a lot of flexibility to customise the output. Generally it really just requires copying a file into a directory and making a few adjustments (adding in HTML, commenting something out, etc), with that file then overriding or becoming an option for a block's output. You can mak some pretty big changes this way by really just hacking at some HTML and some PHP snippets, rather than having to go all-in with custom coding.

Finally, if your site has a lot of structured content you'll want to at some point investigate creating page types and setting them up for use within 'Composer'. Composer is a way to allow you to use a pre-configured form to input content, rather than starting with a blank page and having to input everything with blocks. That's perhaps for later investigation, with my main point being that concrete5 has some great ways to set up a site that allows for the entry of data in an easily repeatable way. If you've got a big site to transfer, you'll want to look for some ways to manage your content in a structured way.

Good luck!

Hi mesuva, thank you for the welcome!

Your comments raised a meta issue that I guess I hadn't considered, so I was wondering if you could offer some insight. Because I'm coming from Drupal, and have used Drupal since version 5, it occurs to me that a) I'll be approaching everything I'm reading and learning from the mindset of someone used to setting up a site with Drupal, and b) that means I'll be approaching the way I organize site information as someone who did this with Drupal, and so c) this might not be a good thing. Or it might, I don't know! But I was wondering if you could just glance at my approach below and tell me if this will fit in will with the way concrete5 works or if there are some basic concepts I need to pay specific attention to so my basic instincts don't walk all over them:

Essentially I view the "Create Content" portion and the "Create UI" portion of a site as separate activities. For the "Create Content," I have to plan out what things I want to keep track of with my content: so for example, for webcomics there will obviously be an image, but then I have to decide what other information surrounds that content: Each comic has a title. Each comic has specific characters that appear in it. Each comic has a transcript of the text in the comic (which makes it more searchable, and also accessible to the blind, who it turns out like reading comic transcripts.) Each comic might be associated with a specific story arc.

So the first part will be assembling the pages where I enter all that data -- a form where I upload the graphic and add all the surrounding information. This field for the story title, this field for the story arc title, this field for all the characters appearing in the story, this field for the comic transcript, etc.

When that's done I have content in a database, but no way for anyone to view it.

So the next part is "building interfaces that take advantage of all that information." There may be different ways a reader wants to view the comic, depending on their needs. If they're browsing through the archives, they may want to browse by year or month (i.e., "I want to see all the comics published in June of 2001.") Maybe they want to see every comic where a specific character appeared. Maybe they want to view all the comics of a specific storyline. Maybe they want to browse through each comic one at a time, starting from the very first comic published all the way up to the present.

In these situations, what I'm really building are interactive database reports, only with embedded media. :) The CMS pulls specific pieces of the data I entered and throws them up on a page (or report) that I'm arranging in a (hopefully) user friendly manner, but it's not for a specific view. So any time a reader decides to look at a single comic, they're viewing a generic "single comic" interface that has been filtered down to "show the comic for a specific publication date" with an added UI element that lets them browse to other comics, because I like having readers who stay.

Separating content and presentation is something Drupal did extremely well, though it wasn't as granular as I wanted, and I assume that's the way a CMS is supposed to work. But maybe I'm wrong about that -- back when I was using WordPress (a very, very long time ago, so it may not be representative of what WP is today) it felt more like the data entry form I was building was also going to be the presentation view I was creating, and that if you wanted to spin off other ways to present the information you had to start looking into plugins.

So will my mindset work with concrete5? I installed a test site on my laptop and just looking through the admin section it _looks_ like it will, but if that mindset will work against me I want to know before I start digging in deep because interpreting what you learn through a bad filter makes everything take longer. :)

You'd want to "build" your database using "Express" I think. That's been introduced in version 8 of concrete5. There are some videos about this:

https://www.youtube.com/watch?v=Fub_Jstvpcs...
https://www.youtube.com/watch?v=p68KEcY543Q...

Better look at some of the videos to get an idea of what it can do. If you have a database already, I'm sure you can write some own code (or let someone write it) to migrate that to fit the Express objects you are going to create.

After creating this with Express, you can make so called "Single Pages" in concrete5 to build the pages to:

- view a Comic detail page
- search in archives by month
- view/browse all comics
- and some other pages that come to your mind

As mesuva pointed out already, concrete5 is suitable for like 99.99% of the things you can come up with. It's really flexible.

Express should work, but you might need to be a bit patient as some early bugs are still being exterminated. Moreover, I don't know if you can go the whole way without having to do a little php—I hope so, but the examples end up getting into code.

One pre-Express way would have been to develop a custom block for a comic. This would involve database field specification and UI. The separation between data and UI isn't crystal clear since both are encapsulated in the block; you could think of the block's add/edit form as the data, and the view as the (user) UI.

A less traumatic route could be to adapt the blog page model, and use a c5 'composer' page to produce each comic page.

c5's initial appeal is in the drag-and-drop WYSIWYG design interface. This tends to obscure the separation of data and presentation, although it's still there under the hood.

At least for the time being I'd also agree with looking to use a Page based approach.
If each entry of content is intended to be display on it's own page, and you want to be able to list such pages, it does make sense to directly create each entry as a page, using page attributes to store the individual pieces of data.

In your case I'd be suggesting something like:
- a top level comics page
- a page type for a 'Comic'
- potentially a page type for 'Comic Category' (or maybe Storyline)

Then you would configure your page type(s) for use in composer, to publish under your top level comics page (or under comic category pages)

On your top level page you can do things like list the 10 most recently added comics, or list your comic categories, or both. If you roll out a default install with sample content you'll see that several page types are set up like this.

You might then create a 'Character' page type in the same way. The trick then is working out how to associate comics with what characters appeared. You could go the manual route and add a block (or textarea attribute) where you can type in the names of the characters and link to their pages. Another option is the use of a Multi Page Selector attribute, but that's perhaps a bit more advanced and requires the install of a new attribute type.

It's not uncommon to create several page types to categorise and nest things here. If you also use the page hierarchy to manage things, you can do point navigation blocks and page lists to certain parts of the sitemap, to create mini navigations.

As Ramon has suggested, Express is actually designed for these kinds of database-y relationships and is worth exploring - the concern is just that it's a still a pretty new feature and you still might hit a few bugs.

I think the main point here is to explore the different options and look to get your head around the data management side of things first. Sounds like you're already thinking well along those lines.

Just to add a little context, we're talking more than 2400 individual comic pages here. While I'm sort of resigned to uploading each manually, at the very least I need some templating, and there's no way I'm willing to make all the individual associations manually. :D

I was thinking of writing about and recommending the page based approach yesterday, but didn't have time. Certainly at the moment it would be my preference over Express for this kind of application.

Further to @mesuva's comments:
- There are many addons for presenting page lists in different ways.
- Pages can also be navigated by various autonav blocks.
- You can use any kind of block within a page.
- They don't all have to follow the same format.
- On-site search works with pages.
- Google can index pages.
- Pages are easier to format/theme.
- You could conceivably derive an XML file for your existing content that could be imported with the c5 content importer to generate the pages.
- Pages can be cached and served statically.
- Pages can be moved & copied easily using the site map.
- Pages can be navigated in the site map.
- Pages have versioning.
- Pages in c5 are better documented than Express.
- Pages are a mature technology.
- For visitors, page lists linking to pages are comfortable with screen readers.