From Fundanemt3

Contents 1 Target audience 1.1 End users 1.2 Administrators 1.3 Users 2 Concepts 2.1 The installer 2.2 Filehandling 2.2.1 Image handling 2.3 GUI 2.4 Page editor 2.4.1 Table editor 2.4.2 PHP editor 2.5 Database 2.6 Parser 2.7 Templates 2.8 Search 2.9 Other 2.10 Statistics 2.11 Modules 2.11.1 Modules, ideas for 2.12 Filters 2.13 User administration 2.14 User administration for front-end users 2.15 Logging and errorhandling 2.16 Cache 2.17 Help system 2.18 Documentation

Target audience

• Small to medium size companies
• Developers (modules)
• People with disabilities / blind people
• Web developers (end user)
• Users (the ones who are browsing a page created by fundanemt)

The users should be serviced in the following categories

End users

• People with disabilities / blind people
• Users
• Developers (make an advanced view avalible)

Administrators

• Web developers using templates
• Web developers creating their own html / css

Users

• Everybody (if possible)

Concepts

The installer

• Select a template
• Select special pages (404 etc.)
• The generated configuration file must only contain a bare minimum of information (perphaps only the access credentials for the database)
• Create users
• At the beginning it should be possible to select between a simple and an advanced wizard
• Select language(s)
• Select modules (by fetching them from the official web page)
• Check for a newer version of fundanemt
• After the installer has completed, nothing should be done (no moving files around)
• Import a database / a complete fundanemt installation.
• The installer should select which charset the web page should use by looking at what the database accepts
• Update function - It should be possible to update from and old Fundanemt 2 to the new Fundanemt 3 - php-elements will of course not always work after and update.
• it should be possible to install Fundanemt in any directory not just in a fundanemt-directory as it is today.
• More focus should be put into installing it as shared installations. It could be with different levels of sharing:
  • Nothing shared
  • Core system shared
  • core system and installed modules shared

Filehandling

• Virtual filesystem
• Upload files via FTP
• Upload several files (http)
• Import files from other directories (see uploading files via ftp)
• Files and perhaps also directories should contain meta data
• Files and directories should have editable access permissions
• General filehandling - like renaming, moving etc. - should be possible from within fundanemt
• When changing a file (deleting / renaming etc.) it should be checked if it affects any links on the web page
• Sort files in the filehandler
• Search for files (using names / meta data)
• Preview files by having plugins for specific file types
• Edit files by having plugins for specific file types
• Zip / unzip files
• The administrator must be able to set quotas on directories and specify which file types a directory may contain
• Quota on directorys
• Enable front end password protection on dirs and files.
• Version control - should it be possible to undelete a file or return to a previous version of a file?

Image handling

• It should be possible to resize, crop and rotate images.
• It should be possible to adjust brigthness and contrast of an image.

GUI

• There should be a GUI abstraction layer in order to enable the use of different GUIs.
• The abstraction layer should consist of xml-files which the GUI-manager should parse.
• As default we should provide two GUI-managers - the div-based one and a lynx-compatible one.
• The Lynx-compatible GUI will not give access to all editing. For example it would make no sence to edit images in lynx.
• Look like an application, containing standard skins for linux and windows (or a common)
• The layout should be div based and resided within a single browser window (div based popups)
• The state at which the user logs out should be saved and restored on the next login
• Ajax should be considered when developing the gui
• Inserting data should be content based (?)
• Maybe support for handling multiple domains from one editor
  • connect to multiple databases OR
  • have multible domains in same database (table-prefix maybe?)

Page editor

• The user should see the whole page, as a page containing text elements, and placeholders for all the other elements (tables / images).
• Each page may containg meta tags (which would either overwrite the global ones or join them)
• each element on a page has it's own revision system where X older revisions are kept and rollback is possible
• When editing an element a flag should be set, so if anyone else tries to edit the same element he gets a warning about others editing the element (this can use a timer to check the likelihood of other editors).
• Elements and pages should be able to be marked as unreleased (hidden) meaning that it will only be shown in previews - not normal visits to the page.
• Elements should be able to have a release data so it automatically gets enabled/released after a certin date/time.
• Style Class chooser for text elements
• a wrapper around the text node element would also be cool. where you can e.g. choose type column and set the column width. Then funda would print divs with the necessary css.
• I would love to have a tool that would contextualy figure out what level of headlines I am on (for instance using ! as the start, and then, if I had -- say -- a h1 and a h2, it would go with h3

Table editor

• It should be possible to melt cells both vertical and horizontal
• A cell could contain images and text - perhapse also php and html

PHP editor

• Syntax highlightning
• Autocompletion on functions.
• Help showing required and optional parameters for a function

Database

• We should consider using an existing database abstraction layer (perhaps the just released PDO in php 5.1)

Parser

• The parser should be able to output to following formats
  • (x)html
  • xml
  • pdf
  • open office xml
  • microsoft office xml
  • tex
• it should be possible to inject filters in the parsing process
• Maybe look for inspiration in the MarkDown parser system http://www.michelf.com/projects/php-markdown/

Templates

• Pure xhtml and css
• Manage page templates (element areas etc.)
• Assign templates on a per-page-basis

Search

• It should be possible to search for information residing in the core, in modules, in the frontend, the menu etc.
• search result should be shown with how much procent "relevant" a found page is.
• The search should also searh in a page metatags if any - this how the user may define keywords and descriptions in order to tune the search

Other

• It should be possible to define the web pages meta tags in fundanemt
• Switching between a languages on a multilingual site, should switch between semantically related pages. Example: Being on the contact Page in german, switching the lang should bring the user to the contact Page in english.
• UTF-8 support

Statistics

Modules

• Multiple types of modules:
  • Normal modules administrated from the backend (shown in the module list) changes/inputs stuff in frontend via hooks. All modules has an module insertion dialog making it possible to add to a page.
  • Backend modules for backend things only (e.g. statistics, user management, show links top10 for links module etc.). Module is shown in module list if access is granted.
  • Editor modules enhances the editor by adding new functionallity (e.g., wysiwyg, file format support, alternative table editor,etc.). Each module is added by admin and is not shown in module lis.
• Modules should be installable/updatable directly from a module repository
• Modules should be able to be uninstalled/disabled if not needed.
• All settings for the modules should be handled in the database (no config files).

Modules, ideas for

• Global Site Parameters Module. A site developer could define certain parameters that a user then can set. E.g. setting a site header image to a certain image or setting it to random. It could be used to control settings outside pages.

Filters

• Filters should be able to be enabled/disabled directly in the backend (no config files).
• Filters should be registered rather than just called one at a time
• Filters should be installable/updatable directly from a filter repository

User administration

• Multiple admins
• It should be possible to create groups and grant privileges on a group.
• A user may be member of one or more groups inheriting the privileges from those groups.
• It should also be possible to assign privileges on a sinle user.
• Privileges should be granted on several actions including create, delete, move pages, upload filetypes, directory access
• A users should be able to control his or hers user profile including language selection and theme selection.

User administration for front-end users

We should somehow be able to handle sites which do not allow all visitors to see everything.

Logging and errorhandling

• It sould be possible to set logging level for info like:
  • logins / failed logins
  • changed/add/deleted pages or page-elements
• It should be possible to get errorlogs for e.g.:
  • PHP errors
  • 404,502 etc.
  • module insertion/installation failures
  • missing images
  • broken links
• maybe the errorlog should be split into one for:
  • web related errors (404, broken link etc)
  • system errors (PHP, module stuff etc.)

Cache

• Generate a static html-file hierarchy in order to diminish server load and page load

Help system

• There should be a help button in every toolbar so that the end user could get help to that exact dialog/function.
• The help system should be able to load the end user manual writtin in latex ( perhapse translated first with latex2html )
• Each module should provide its own handbook.
• The help system should provide a search

Documentation

• All classes, methods, functions etc. should as a minimum be described with a phpdocumentor(phpdoc) compatible format.
• All methods available to the user should preferebly be described with an example in the phpdoc and should be described in the official fundanemt userguide and API description.