[RULE] Re: Restricted requirements for RULE website

[C David Rigby]

Hello all,

I've been knocked out by a cold for about a week, so I am only now 
starting to get back to looking at this topic myself.  For those that 
are interested in this topic, please provide some feedback concerning 
the tentative conclusions I make below.

I have superficially examined about 20 CMSs, and narrowed the list down 
to four that I wish to examine in a bit more detail.  See the title _CMS 
Options_ below Marco's comments.

In summary, all CMS packages seem to require modification and/or 
extension to meet the goals as Marco outlined previously.  Active CMS 
projects may well be willing to help us achieve this goal, if that seems 
interesting to them.  Rodolfo's security concerns are well-founded, and 
we need to satisfy his criteria before we throw an interactive site on 
his server.  I intend to investigate using a basic Apache/PHP/MySQL 
system such as Spip, or create our own site with basic tools starting 
from Marco's current work.  In the latter case, I propose to discard the 
use of MySQL entirely, assuming we can satisfy security requirements of 
the server admin.

Details below Marco's revised text...


M. Fioretti wrote:
> Hello again,
> 
> Please answer only on the RULE list, to make discussion
> faster. Ernesto, please subscribe if you didn't already.
> 
> I have realized a couple of things about the requirements I posted on
> Feb 20th (pasted below for your convenience).
> 
> Most CMS packages seem to me geared to maintain different kinds of
> sites: news portals, where one posts announcements, and people
> vote/discuss it in the attached forum. We need something where almost
> no interaction with end users happens online, but I and other
> volunteers can as quickly as possible (and from web browser behind
> firewall):
> 
> 
>    a)	upload / update semi-static many web pages at once, software
> 	tarballs, PC test data and and actual news
> 

NOTE: I am going to refer to this as "Batch Mode Updating" or "BMU" below.

>    b)   make the corresponding updates to a mysql database (always
>         through php/html forms)
> 
>    c)   announce changes through the mail list and an RSS feed
> 
> All this should also have roles: registered contributors can upload
> stuff/update database, but changes are not seen online (unless they
> are already well known contributors, marked as "trusted" or
> something). One admin (me) deletes or authorizes contributions from
> others after checking them (always from browser behind firewall).
> 
> Everything else I posted last time is either optional or independent
> from CMS (like setting up our mail/ISO ftp server) or we already have
> it (site map and mirror generation) and should only patch the
> existing scripts to make them work with any new solution.
> 
> Also one time maintenance stuff (creating new mysql tables, new
> folders, whatever) I can do from home, ie ssh, any https ports, etc...
> What matters is to make it possible for others to contribute *content*
> quickly only from browser, and for me to do daily maintenance and
> updates in the same way.
> 
> Enclosed please find the php forms (with dummy user and password) that
> I tried to write last year to do the above. It may be faster to do the
> new RULE website starting from them, rather than learning and
> underutilizing any CMS package, I don't know. Feel encouraged to prove
> me wrong.
> 
> Of course any final solution will have to pass Rodolfo's security
> check. Rodolfo, may you post on the list the exact reasons why these
> forms were a security hole?
> 
> (if you don't find attachments, the list manager stripped them: ask me
> off list, and I'll send them the same way)
> 
> Ciao,
> 	Marco Fioretti
> 

_CMS Options_

As Marco has indicated above, and I concur, most of these packages are 
designed to support a particular type of site.  For example, a number of 
CMSs bill themselves as "collaborative development" site builders.  Sort 
of what we are doing.  But these produce sites that are essentially 
distributed project managers, and not designed to be viewed by the 
general public and potential end-users.  So, not appropriate for us.

Our goals do not exactly overlap any particular design (newsite, blog, 
etc.) which leaves us to consider either a more general toolkit for 
website design that will allow us to (eventually) do what we want, or to 
take his current design as the starting point to create something using 
the more basic tools.  The most basic requirement we have is the "batch 
mode update" or BMU that allows people with only slow, switched 
connections to the internet to effectively contribute to the site.  I 
(and others) have some ideas about this which I will elaborate on below 
under the title _From Scratch_

General, flexible packages will allow us to do anything we like.  The 
disadvantage is the learning curve.  By the time one has learned to use 
a large package to create the site, one may have spend the same time and 
effort as would have been used to build it up from the basis of Marco's 
scripts.

Of the four packages, three seem to be of the large & flexible variety:

PostNuke

http://www.postnuke.com/index.php?module=Navigation

Large, flexible, and could probably be programmed to wash your car as 
well as build a website.  No doubt many people have built their careers 
on using this tool.  Part of a whole slew of similarly-named CMSs: 
PHPNuke, OpenPHPNuke, OSC2Nuke, etc.  Sounds like the original project 
underwent a split, à la Free/Open/NetBSD.

TikiWiki

http://tikiwiki.org/tiki-view_articles.php

Wiki-type news site.  So it solves the informational mission well for a 
first-time viewer, and the contributor that has persistent, inexpensive 
internet access.  But I still need to investigate whether it allows us 
to perform BMU or whether we need to add that ability ourselves.

XOOPS

http://www.xoops.org/modules/news/

Object-oriented design, but still /Apache/PHP/MySQL "under the hood." 
Possibly a good choice for a foundation if we need to perform heavy 
modification to meet our specific needs.

SPIP

http://www.spip.net/

The most attractive thing about this package is that it seems to have 
taken a minimalist approach to its design.  So, hopefully resource 
utilization, both on the server and on the part of the viewer, is kept 
to a minimum.  However, it was designed for online magazines, so to meet 
our needs, modifcation/expansion would be necessary.

_From Scratch_

So do we save time & effort with a CMS, or is it better to continue to 
develop our own solution?  Frankly, I am not yet sure.  The first CMS I 
would take a look at would be SPIP, since it seems likely that I could 
comprehend it the fastest.

A number of suggestions sent to the list over the last two weeks on this 
topic address ways of carrying out one or more of the functions that 
Marco described in his first posting.  In particular, we seem to be a 
group of admins and scripters, for the most part!  So taking those ideas 
into account, we might also consider the following (COMMENTS, PLEASE! 8-):

1) Start from Marco's design, where we already have our style sheets, 
layout, etc.  Nothing is wrong with the logical structure of the site as 
presented to the viewer, as far as I am concerned.  We wish to add more 
features (e.g., RSS feed, Project News, etc.).

2) PHP-based administration.  This is where the CMSs shine, and where 
most of the work would need to be done if we create our own.  I prefer 
to use SSH to access remote systems, but not everyone can use that.  So 
we need a solution that runs over http/https on standard ports, provides 
multiple levels of access to different users, and has been 
sanitized/sanity-checked to not constitute a security risk to the 
server.  This implies that the scripts must do input checking and that 
script privileges on the filesystem will be tightly controlled.

3) The "radical" structure I propose here is to do away with the MySQL 
or other database.  Apache does a good job of restricting a particular 
user's content and scripts to the directory ~username/public_html if the 
configuration is set up for it.  So, let the filesystem under 
~username/public_html/ BE the database.  For example, as suggested by 
Rodolfo Paiz, news items could be text files with a header line parsed 
by a script that can be used to rank by date, sort by poster, etc. 
Similarly for test PCs in the testing farm, each machine could get a 
directory that would hold a text or even a flat HTML file with the 
technical specs, installation report results, etc.

4) BMU by testers is accomplished by downloading an HTML template and 
"filling in the blanks."  It is then uploaded, parsed by a script that 
strips off the instructions, and Marco or the designated maintainer 
installs it into its own directory and it becomes available on the site. 
  A similar mechanism could be used for other functions such as news 
articles.

5) Mirroring is easily accomplished with a tool such as RCS, assuming 
that is available to us.  Otherwise, a simple script could drive the 
production of nightly tarballs (something we want anyway) that mirror 
ops can download on demand.

-------------

I am a newbie to PHP , so I may be thinking that it can do things that 
it really cannot.  Comments, please.  I've got my flame-proof suit on - 
FIRE AWAY!  {8->

CDRigby
cdrigby at 9online.fr

> On Fri, Feb 20, 2004 11:06:52 AM +0100, io  m.fioretti at inwind.it  wrote:
> 
>>Hello,
>>
>>following the several suggestions on how to manage the website, here
>>goes a random list of requirements. The bottom line is that I know quite well
>>what is missing, but have no deep experience of the several CMS
>>solutions suggested, or of others. I do know my bit of perl, mysql and
>>php, however, and am more than willing to maintain the site.
>>
>>This means that I can patch and improve something that already exists,
>>but very frankly have no possibility now to set it up from scratch
>>(including building the required forms or installing any CMS sw).
>>
>>Hence, please, please please somebody else do set up now whatever
>>solution, according to the guidelines below. I'm eager to help with
>>*testing* it and take since now the responsibility to take it over and
>>maintain it, tweaking whatever configuration and PHP/mysql bits
>>will be necessary later on the road.
>>
>> I "just" :-) need to find the initial framework as below in place.
>>
>>Of course, almost nothing below is set in stone. Any feedback is,
>>well, mandatory :-)
>>
>>Deadline: none mandatory, but it would be really, really nice to be
>>ready when FC2 is released (~ early april, IIRC) and for that
>>Ethiopian ICT congress I mentioned yesterday.
>>
>>Thanks in advance,
>>
>>Marco Fioretti
>>
>>content in pure text format??:
>>
>>    frankly, I personally find adding stuff in a web form (wiki-wise)
>>    expensive for dialup contributors and in general cumbersome and
>>    limited (unless you do everything outside in a real editor and
>>    then just paste it into the form). This is why I tried to set it up
>>    web content as today:
>>
>>	produce pure ASCII content, without an HTML editor, with such a
>>        markup that the source is perfectly readable.
>>
>>        upload the ASCII text
>>
>>	have a cron script converting it to HTML
>>
>>    If this is not possible using standard CMS system nor recommended
>>    by more expert webmasters, html is also OK for me as long as it
>>    remains possible to
>>
>>	     not care of site layout, ie generate/maintain only the
>>	     actual page content (no headers, footers, etc)
>>
>>             do it offline and upload the result
>>
>>             upload at once many pages, specifying for each its
>>             location in the directory tree
>>
>>	     insert in each page pointers to chunks of PHP code (see
>>	     as example the source of the current home pages)
>>
>>Access to manage web site:
>>
>>    everything below must be doable via web (https) but not on ports
>>    usually blocked by company proxyes and firewalls. One big problem
>>    I have with the current system is that I can't do RULE
>>    housecleaning during lunch break.
>>
>>roles:
>>
>>    I must be able to delegate upload of files in some areas and
>>    posting of news to other project members. It must also be possible
>>    to external users to submit news, test PC data/reports and sw
>>    packages in a "pending approval" mode: they don't show on the web
>>    pages, but I am sent an email to go and reject or approve for
>>    publishing the new material.
>>
>>Interactive threaded web forums:
>>
>>    not needed, really. Most of our subscribers, current and
>>    potentials, have no decent conectivity to use them, and want/are
>>    forced to stay online as little as possible.
>>
>>news:
>>
>>     it must be possible to insert news (title, link to complete
>>     article, short description) so that the N most recent are
>>     constantly shown on the home page. Complete news database must
>>     remain readable online, as today.
>>
>>useful links
>>
>>     it must be possible to insert links to useful non RULE resources
>>     (title, category, URL, short description) so they are all
>>     displayed in a bookmark kind of page
>>
>>threaded customizable site map:
>>
>>     an evolution of the current one: show directory structure, size
>>     and change date, show only some subdirectories, or only the pages
>>     updated in the last N days.
>>
>>web page management:
>>
>>    it must be possible to show as today the N most recently changed
>>    web pages on the home page
>>
>>mirror friendliness:
>>
>>     easy to mirror automatically: HTTP headers telling what changed
>>     since last weeks, relative URLs, etc..
>>
>>support of test PCs and software map at least as today.
>>
>>when news, new pages, or new SW is added, they should be announced
>>automatically on mailing list. RSS feed generation is also very nice.
>>
>>*LIGHT* HTML code and page layout:
>>
>>     The site structure and content must certainly become easier to
>>     understand and navigate than today, but think to people trying to
>>     know how to get RULE through a 14.4KBps modem, links, a 486 and a
>>     monochrome monitor (not to mention blind users). Let's limit as
>>     much as possible frames, nested tables, colors, JavaScript.
>>
>>tarball(s) with all the site content and mailing list archive must be
>>generated daily and available for download.
>>
>>     the reason is to make possible easy download and offline
>>     consultation of all RULE site, also for the purpose (as it
>>     happened last summer for Linux Pakistan to burn and distribute it
>>     on Cd-rom
>>
>>multilingual support: yes please
>>
>>search whole content: yes please
>>
>>
>>
>>_______________________________________________
>>Original home page of the RULE project: www.rule-project.org
>>Original Rule Development Site http://savannah.gnu.org/projects/rule/>>
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list
>>
> 
> 


_______________________________________________
Original home page of the RULE project: www.rule-project.org
Original Rule Development Site http://savannah.gnu.org/projects/rule/
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list