• View
• Edit
• History
• Attach
• Print
• Backlinks

NetstreamsCMS-Talk

Comments

DirkBlaas (2009-09-14)

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

cmstrekker (2009-02-26):

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.
  1. Login as admin
  2. Menu / Administer / Layout Settings / Site Dimensions / Site Width
  3. 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
     • http://demo.netstreams.org/cms/index.php/Test/FluidWidth
     • http://demo.netstreams.org/cms/index.php/Test/FixedWidth
• 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

cmstrekker (2009-03-03):

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.