database-generated dynamic content with c5?
I just inherited responsibility for the website of a nonprofit,
built/maintained in c5. I can modify the existing website, no problem.
I'm moving the nonprofit's print archive to digital form,
using PHP pages I wrote to maintain a MySQL database (outside of c5).
I'd like to have the c5-based website access the archive database
to generate dynamic content. Is there a reasonably clean way to do so,
or do I just kludge something together with duct tape and bailing wire?
You'd probably want to set up one more 'single pages' in your system, this gives you the ability to use a MVC pattern.
(Scroll down to the heading 'Creating the single page')
The other option is you create some custom blocks that pull in the data manually.
This might be a good starting point:http://www.concrete5.org/documentation/introduction/model-view-cont...
Once you dig into it, the concrete5 API is very strong and there is a huge amount of functionality built in.
If that's the case you have some options. I'm guessing your database is already created and you want to keep that? If so you would be happy to know that Concrete5 is MVC based. You can create a Print Model(in the models directory) and do all of you database sets and gets from that abstracting your additional database away from kludgetopia.
Then you would be happy to know that concrete5 has this concept of what are known as "single pages" These are pretty much anything goes pages that essentially get wrapped in the theme(typically a header a footer and maybe a sidebar). You would probably end up making one or more of these to be the main search and display of your photographs. On that note you probably look into the DatabaseItemList class as opposed to raw sql, but the choice is yours.
You could also create additional "Blocks" for displaying certain pictures in other parts of the site, like the landing page or other clever spots you might think of. Blocks are also somewhat MVC-ish and you can use your Print Model you created up above for those as well.
I see you have already gotten a couple good links and suggestions, so I'm sure you'll have some questions later on. No cms is kludge free but concrete5 certainly has quite a few anti-kludge powers.
I'll dig into single pages and follow up on the other posted links and let you know
of my progress.
The organization I'm doing this for has been around for 27 years.
We have hard-copy binders with interesting info dating back to the beginning,
computer-based files dating back a decade or so, and 20+ years of audio
in various formats. The website currently describes the present adequately,
but I'm looking to incorporate the past in a structured fashion.
But since you're new to C5 I want to suggest that if it's possible to put your archived content into the C5 site itself and make them actual pages and part of the sitemap, that will be a better situation because it then fits in with the rest of the system. C5 revolves around pages and the more you can make things individual pages, the better. For example, if you have them as their own pages of content, you get this automatic functionality out of the box without having to code anything:
* search functionality
* version history (which may not apply if nobody is ever changing this historical content)
* security/permissions (again, maybe doesn't apply to your situation)
...and probably some others I'm not thinking of.
I don't know the specifics of your situation, so I'm not suggesting you go this route, but I did want to explain the benefits of it so you can make a more informed decision. If you do want your legacy content to be imported as actual C5 pages, then your task changes from creating a page to query the database and display content (which is what you'd do with a single_page) to a one-time import script that programmatically generates C5 pages and puts content blocks in their areas.
Let me know if you need some more pointers about either of these approaches.
PS: Congratulations -- you've managed to get the 4 smartest and best-looking people in the C5 community to respond to your question :)
> PS: Congratulations -- you've managed to get the 4 smartest and best-looking people in the C5 community to respond to your question :)
Plus me makes 5.
I see your point re single pages vs. actual pages for underlying content, but I'm skeptical.
One part of my project involves an audio archive, currently ca. 10G in a few hundred
.m4a files, some of them large (>64M), reasonably well organized. I can upload
these outside of c5 with a single scp -p command and end up with the tree-structured
archive I want, albeit outside of c5's purview. Can the c5 File Manager do that
without considerable effort on my part? More power to it if it can, and I'll be glad
to use it. But I see a "64M max size" limitation, for starters...
Attaching a file to a "page" isn't really a big deal. If you really want to spend time thinking about how cool it is to know about scp then you are probably better off building this part with something like code igniter/zend (Zend is easier to hook into in c5) than to attempt to work within any CMS type situation. Then just spending your time hooking them together.
CMS's are not at all designed for developers to do whatever they want. They are designed for end users to do as much as possible with very little knowledge. To use them as a developer you have to work with them not against them.
Concrete5 has ways to do all of what you want, but it feels like you are already upset about having to deal with it in the first place which will inevitably lead to frustration and failure.
Then have a think around importing a description with all the metadata for each into C5, either as a content block or as a text file via the file manager. That would give you the search functionality. Then you need to tie a link from that to a player (the single page? or are the files compatible with one of the existing player blocks and addodns?)