CMS Made Simple Forums

I'm trying to find out where the content for static pages is stored in the MySQL database. I see that the text seems to be stored in 'cms_content_props' table in the 'content' field, but the page title and other crucial info seems to be located in the 'cms_content' table. How are these tables related, or am I looking in the wrong place?

Related question: is there a visual schematic of the CMS database? Wordpress has a nice one at http://codex.wordpress.org/Database_Description, and I'm slightly envious.  ;)

Many thanks!

"cms_content_props" contains column "content_id", something like foreign key to "cms_content.content_id".

I have not came across any UML diagram for CMSms yet.

kingfhb wrote: This didn't really seem to answer the question, of which I have the same. I have searched through the database with no luck in finding the actual content page data. That is, the content for each page that I have typed in.

Just looking for the location of where this is kept so I can copy the text... any ideas?

The actual page content is in cms_content_props.content.

Thanks all for your answers. I think I've got it figured out.

I'd be willing to help diagram the database, but I'd need someone to help me figure it out. Anyone skilled in the CMSMS database want to collaborate? Sketches on a napkin, existing notepad diagrams, anything that exists might be handy. Wouldn't be an overnight sort of project, but I'd be happy to finally give back to CMSMS. I'm a frontend developer, so my skills in this department are somewhat lacking. But I bet I can make one heck of a pretty diagram.

perhaps an ERM tool like this could help you get started?

http://schemaspy.sourceforge.net/

The database schema is not a closely guarded secret.  Infact, it's not that tough to figure out.  However, we don't advertise it, and don't really support direct accesses to the database because

a) the schema is subject to change at any time
    - we won't support any plugins or programs or whatever you've written to directly access the database.
b) There is an api that we do support

Hope this helps.

Would others find it useful?

I understand your point Calguy, and it wouldn't be prudent to make plugins like that, but there are times that you simply must go in and use the database for weird circumstances. I think a road map would be quite handy. I spent many hours searching through tables trying to locate the various pieces. With a diagram, I would have been able to solve my issue much faster.

Maybe an DO NOT USE THIS FOR PLUGIN DEVELOPMENT. USE THE API INSTEAD. would suffice?