Summary: A CMS (Content Management System) extension for pmwiki features different page-types (article, blog, comment issues), separation of content and layout, basic workflow capabilities, content-type based authentication and wysiwyg editing.
Questions answered by this recipe
Is there a content managemet extension which features:
- different page-types like Article, Blog, Issues, Comments
- easy setup of custom page-types
Fully templated and web based configurable Layout
- separation of content from layout
- Configure layout settings via form for the entire site, a group or a singe page.
- Desktop-Application like menu to manage all author and admin tasks
- Qualification of content, examples: live cycle, status, priority and responsibility
- Status Page sortable by pagetype status livecycle etc.
User Authentication & Permissions
- Page-Type based permissions. Per group customizable authentication-groups for each page-type.
- Tiny MCE integration (optional)
A CMS (Content Management System) extension for pmwiki features different content types (article, blog, comment issues and custom types), seperation of content and layout and basic workflow capabilities.
Try out a demonstration: http://demo.netstreams.org/cms Login/Password is Author/test or Admin/test.
- Download the packages listed below and copy it into your pmwiki directory.
- Download the complete demo and copy it into the web directory.
- copy /docs/netstreams/sample-config_local.php to /local/config_local.php.
- change the settings for
- author password
- admin password
- session variable
This is a experimental release. Weekly Releases. Suggestions and bug reports are very welcome.
I am very interested in the promised 'Tiny MCE integration (optional)'. but I can't find it in the solution set and allso nowhere on the Netstreams demo. False promise ??
- No false promisses here (everything, experimental) ;-). In fact it has to be enabled in the config file with $WYSIWYG = 1; and the textarea must have the css class mce_simple or mce_advanced. I did this for the pagetype "Article". So create a new Article or edit this page and you can check it out. In a feature release it may be configurable in the pagetype-configuration form. grz Benjamin? September 17, 2009, at 04:13 PM
It's fantastic. Don't go too fast into databases, because enough CMSs force that, and few have flat file support.
- don't worry, I would like to support both, see Cookbook:SQLite, but db for pmwiki would have a lot advantages:
- to index PageTextVariables would give much better possibilities for pagelist queries
- more performance effective, currently, only using ptv's in a pagelist definition ( $:pagetype=Article ) is very expensive cause pmwiki has to open each file in wiki.d
Suggestion, the skin(s) lack fluid resize. Check Maguila re Holy Grail, One True Layout. Consider also full fluidity, like Lazy Days. Other ideas are FooterStickAlt and Deluxe CSS Dropdowns and Flyouts.
- Fluid resize is configurable (webbased). Default is a fixed width (1000px). It's easy for an admin to change that (for the entire site, a group or a page) to a relative value.
- Login as admin
- Menu / Administer / Layout Settings / Site Dimensions / Site Width
- Enter a relative value like 90%. The site is centered in the middle, and the width is 90% of the window width. This should give you the resize you want. Example
- What divs vs tables concerns, I would like to use div's instead of tables, but couldn't get it to work well yet.
I don't know, but you might peek at WYMeditor.
- I plan to implement a wysiwyg-editor and checked out wymeditor. I think this editor has a very promising concept. However the table feature is a bit minimal and don't work very well in firefox. See: http://forum.wymeditor.org/forum/viewtopic.php?f=2&t=463. But to my this is a main reason to switch to wysiwyg, so I my have to wait or look for another editor.
Thanks for your feedback, grz Benjamin? March 03, 2009, at 12:47 PM
Comments on the above (thank you).
WYSIWYG defeats markup concepts, slows interactions, and is mega work. It's best for client apps like NvU. WYSIWYG eats coders for lunch.
- In pmwiki it's actually quite simple. Enable the html tags the editor uses and disable problematic (or alll) markups.
Designers consider tables klunky old-school. They like DIVs with CSS/XHTML compliance.
- I agree in terms of site layouts, but authors will always need tables, thats way I need a wysiwyg-editor with strong table features.
DBs help with lots of data, but hurt with less. Zillions of PHP/SQL solutions exist: same-old, same-old.
A filesystem is a DB, and can outperform SQL. A tmpfs-formatted ramdisk can easily hold the text of a site. I'd like a CMS with pure .txt files. You'd beat all SQL solutions. In /etc/fstab,
tmpfs /mnt/ramdisk tmpfs rw,nosuid,noexec,noatime,size=100M,nr_inodes=2k 0 0
(A cron job can rsync to physical disk every so often as backup.)
The wget trick for static pages runs circles around all PHP/SQL templating. Pages where comments are closed work fine this way.
User notes? : If you use, used or reviewed this recipe, you can add your name. These statistics appear in the Cookbook listings and will help newcomers browsing through the wiki.