- added `CMS_USER_API.user_with_credential (...): detachable CMS_USER` that check if credential is valid, and return associated user.
- replaced use of `is_valid_credential` by new function `user_with_credential` .
- revisited the session auth, to allow other credential validations (other than ROC CMS auth).
- added CMS_USER_API.credential_validations to allow authenticating with system other than ROC CMS.
Added new permission to allow by-passing the default ROC-CMS user login/register management:
- new permission to edit its own account.
- new permission to edit its own password.
- new permission to view users details (mostly for user managers).
Removed useless and unimplemented feature from CMS_FORM .
SCOOP is default for demo.ecf
Made blog and page module self administrable, i.e administration module is same as module.
This fixes the export hook for page and blog modules.
Improved sql instructions to ease debugging and catch missing sql_finalize... call.
Cleaned sql code.
Added permissions on basic auth, to have more control on who can authenticate with basic auth.
Use webapi version of basic auth filter.
For webapi, when authenticated /api/user/ is the same as /api/user/{uid} where uid is the id of current logged in user.
Added authentication module webapi, to provide registration via webapi.
Improved the roles display by providing table of permissions if asked.
Added various links in primary tabs to navigate back to roles or users, depending on the page.
Added datetime to-from string converters in CMS_ENCODERS.
Start removing CMS_ADMINISTRABLE.
Added permission to use simple core access token.
Added webapi for users: list, new, register.
Fixed modules admin handler permission checking from "admin.installation_access" to "administration.installation_access".
Use constants for known form id.
Invoke hook form alter for user view response.
Include theme when installing roc cms library.
Added sql_delete routine to replace sql_modify with "DELETE FROM .." sql statement.
Fixed filter setup when a module has more than one filter.
Fixed filter setup for site,admin and webapi modes.
Added CMS_AUTH_FILTER, and check if user is already authenticated, then skip following auth filters.
Added specific webapi handler classes for root, user, access token, ...
Added user profile system to the core module.
Moved /user/{uid} from auth module to core module.
Added possibility to add html before and after a cms form. (useful to add a form before or after, as nested form are forbidden).
Now theme can be installed using roc install command.
Added support to choose either atom or rss for the "/feed" format.
Added support for feed format view to feed aggregation.
Use proper content type for RSS and ATOM response.
For feed aggregation use `?view=feed` or `?view=feed.atom` or `?view=feed.rss`
Improved sized feed view.
Use site name for recent changes feed title.
Better name for node feeds (include the site name).
Use current date when a feed aggregation is converted to a new feed, to set the last build date.
Fixed category filter per feed location for the feed aggregation module.
Fixed authentication module, where a potential case (but not probable) had no response content.
Cosmetic and minor changes on messaging module.
When access is denied, also provide when possible and wanted, the needed
permissions so that in the future, user will be able to ask for
permission easily.
Renamed previous user handlers as admin user handlers.
Added non admin user handler /user/{uid} .
Add new `send_...` response to `CMS_API.response_api`, and use them
instead of `create {...RESPONSE}.... ; execute`.
Fixed potential issue with storage mailer initialization if folder does
not exist.
Added utf_8_encoded helpers function on CMS_API interface.
Fixed a few unicode potential issues.
Removed a few obsolete calls.
- Added $theme_path, $base_path
- Added CMS_RESPONSE.module_resource_url (...) instead of using hardcoded "/module/" + name + ...
- Use base_path rather than base_url (note ROC CMS is not yet working with EWF standalone "base" url option)
- Fixed new user insertion in SQL database.
- Removed temp user when activated.
- Renamed local variable names related to temp users.
- More information when error occurs during user registration.
- it allows to login as a given user by passing security check.
- it must be used only during development!
- disabled by default!
Updated the session auth module to make it easier to be reused.
- masquerade module is based on the session auth module.
This optimises a bit the routing map, and make cleaner separation.
Make the base url for admin pages customizable via `administration.base_path` variable in cms.ini
note: could be /admin, /roc-admin, or ..
It is possible to have a specific theme for administration via the variable "administration.admin"
If user has permission to edit, provide a text input, otherwise just a label if path are required.
Reviewed html generated for taxonomy field in node edit form.
Improved the blog entries list by providing (if permitted) link to blog entry creation, and link to the user entries or all entries.
The table nodes and node_revisions have an extra "editor" field.
Update the sql table with:
ALTER TABLE nodes ADD editor INTEGER ;
UPDATE nodes SET editor = author;
ALTER TABLE node_revisions ADD editor INTEGER ;
UPDATE node_revisions SET editor = author;
- List node by node types
- fixed the trash/restore/delete workflow
Added messaging module to send message to cms users (by email for now).
Added early protection for cache, export and import functionalities.
- added a permission to edit path alias.
- added an admin handler to manage path aliases.
When path alias is changed on node, always keep previous path alias.
(can be unset from the related admin section).
CMS_API.storage.path_aliases returns the list of path aliases (recents aliases come first).
Added CMS_USER.profile_name .
Improved module managements with install vs enable.
- enabled/disabled status can also be stored in database.
Install procedure do not install all available modules anymore.
Display /nodes sorted by changed date.
Improved the import form, and report wrong import folder. Only import from folder inside site/import for security reason.
Added basic support for comments, for now mainly viewing comments from database (no submission forms yet).
Added first simple wikitext filter (render wikitext content as xhtml).
Ensure response content type is text/html with utf-8 charset.
- now, the CMS_PAGE_MODULE has to be declared in the related CMS_SETUP via CMS_EXECUTION.
(See demo for example)
Improved the export facilities.
Implemented blog and page export.
Added import facilities.
Implemented blog and page import.
Improved node revision web interface (allow to edit a past revision, in order to restore it as latest revisionm i.e current).
Removed specific tag from blog module, and reuse the taxonomy module for that purpose.
Added WIKITEXT module that provide a WIKITEXT_FILTER, so now we can have wikitext content.
- for now, no support for wiki links such as [[Foobar]].
The installer can now use a roc.cfg file to define the various needed modules.
Format:
{ "name": "demo", "location": ".",
"modules": {
"foo": { "location": "path-to-source-of-module-foo"; },
"bar": { "location": "path-to-source-of-module-bar"; }
}
}
Fixed typo in auth post password message.
Make sure to keep site_destination set in login form, so that the user is redirected to previous location.
Use default http client in the feel aggregator component, instead of forcing libcurl usage.
(This is important, otherwise it uses the current working directory, but for fcgi, this is not always obvious where it is.)
Allow advanced upload, and also basic html upload, in case the dropzone.js has trouble.
Split get and post handling for files module upload request.
Contribution from Fabian Murer, as part of an ETH student project.
Supervised, refactorized and merged by Jocelyn Fiat.
Signed-off-by: Fabian Murer <fmurer@student.ethz.ch>
Signed-off-by: Jocelyn Fiat <git@djoce.net>
- Removed CMS_REQUEST_UTIL
- centralize a few request related code into CMS_API
Added CMS_API.user, CMS_API.set_user (CMS_USER), ... and user related routines.
Refactored Auth related code
- added various abstractions to factorize implementation and harmonize solutions.
- revisited the logout strategy.
- updated the account info page, and remove info user should not care about.
- simplified the process, and encourage auth module to follow same design.
Added CMS_LINK helper routines to modify the related query string.
Removed CMS_USER.profile (and related routines)
- It was not used so far.
- it will probably a specific module later, if needed.
Update various module to avoid fetching user from sql directly, and let this task to CMS_USER_API.
Removed CMS_NODE_API.node_author (a_node: CMS_NODE): detachable CMS_USER,
- as the info is already in CMS_NODE.author
Added CMS_RESPONSE.redirection_delay, if ever one code want to redirect after a few seconds.
Added the request uri info to the not found cms response.
Improved Auth related module implementation by having a way to change settings like token, max age.
- use CMS_SETUP.site_id and related "auth.$module.token" ... configuration values.
- removed related CMS_..._CONSTANTS classes.
For auth session module, use auth_session as table name, and use VARCHAR(64).
Extracted sql from blog module, and store it under site/scripts/install.sql .
Renamed a few $modulename.sql as install.sql
For now with basic implementation.
It will be improved later
Added SEO related attribute in CMS_RESPONSE.
Added improved Contact module.
Added basic SEO module.
Added optional "mailer.subject_prefix" configuration item.
Added CMS_SETUP.utf_8_site_name for convenience.
Fixed a few potential unicode issues.
Fixed various typos.
as a consequence, removed usage of email_service library.
Updated the meaning for site.email to be sender email addressed.
Added notification.email to set the email address that will received system email notification.
Replaced hardcoded name "ROC CMS" for placeholder $sitename, and
missing href's with $host.
Renamed database script and database table for temporal users.
Renamed CMS_AUTH_API AS CMS_USER_TEMP_API.
Revert design to use CMS_TEMPORAL_USER and clean CMS_USER.
Refactor rename cms_auth_storage_* classes to CMS_TEMPORAL_USER_STORAGE_*
Added Pending Registrations to the admin menu to show the list of pending registrarions
added CSS to display temporal users
temporary users.
Updated message, after account reactivation.
Updated message, post account application.
Updated Form name, Registration instead of Registration Form.
Updated CMS_USER to have two optional features used for temporary users.
Updated CMS_AUTH_API to user CMS_USER instead of CMS_TEMPORAL_USER
Removed CMS_TEMPORAL_USER
Updateed CMS_AUTHENTICATION_MODULE, with new permission to enable
activate, reject or reactivate a pending user registration.
Updated User Storage and API to create a new user from a temporal user.
Worlflow
1- Register
1.1 Create a new temporal user
1.2 Email to the new User
1.3 Email to Web Master
2 Web Master Review th Account Application
2.1 Accept and Send an confirmation email to the user and remove the temporal user
2.2 Reject the application send a rejection email to the user and remove the temporal
Added a new table to save temporal users to review their Application to the site.
Updated Register Form with an new input Application and Recaptcha validation.
Updated Emails templates and messages. (TODO improve messages)
Updated mails templates. Simple messages (Todo improve messages).
Added a new handler to reject a user
Updated existing hanlders to handler the new workflow.
- create term, vocabulary, add or remove term from vocabularies, ...
Fixed content editing related to taxonomy (especially with multiple terms vs tags).
Fixed various SQL storage issue related to taxonomy and vocabularies.
Added CMS_RESPONSE.wsf_theme as helper.
Moved content_types and content_type_webform_managers from CMS_RESPONSE to CMS_API.
Updated the way to output content (node, ...) to html page.
See CMS_CONTENT_TYPE_WEBFORM_MANAGER.append_cointent_as_html_to (...).
Added notion of "teaser" (short version of the content), as opposed to full content.
One can use CMS_API.html_encoder ... when possible, same for `formats', ...
Added bridge from CMS_MODULE_API to CMS_API's encoders.
Added new CMS_TAXONOMY_HOOK used to retrieve list of content associated with a specific term.
Moved up to CMS_RESPONSE a few features which was available only in specific descendants.
Added /taxonomy/term/{termid} implementation.
Updated node web form, to support taxonomy editing if allowed (specific support for CMS_VOCABULARY.is_tags: BOOLEAN).
Added notion of required or optional module dependencies.
Indeed, hooks does not require RESPONSE interface,
and should be setup before, at the system level (i.e CMS_API)
Added exportation solution via CMS_HOOK_EXPORT.
Updated blocks settings for demo example project.
(mostly to help new project based on ROC CMS).
Renamed and simplified the roc cms server launcher, and the related cms execution.
Updated cms.ini and extract blocks related management into blocks.ini.
Added debug clauses for cms sqlite3 storage.
Added weight data to CMS_BLOCK to be able to sort the block lists,
and thus order the display of blocks.
Set negative weight for various core block, so that they appear first as expected.
The weight can be set and overwritten in cms.ini , by pref blocks.{block_id}.weight=integer_weight.
Clean code.
Updated google custom search to handle quota limit and no query submit.
Updated encoding issues for input searches: like "void safe" and "void + safe".
Prepared evolution of feed module, by allowing json object to list feeds locations.
The associated key will be used to identify the location, and have category filter by location.
- for block {block_id}, to have a cache with 3600 seconds of expiration,
declare in the cms.ini
[blocks]
{block_id}.expiration=3600
Added support for size in feed aggregation with new field "size"
Redesigned the CMS_BLOCK system,
- added condition attribute. It can be set via configuration file
with
[blocks]
{blockid}.region={region_name}
{blockid}.conditions[]=is_front
{blockid}.conditions[]=path:location-path/foo/bar
- For backward compatibility, the CMS will check only conditions for block name prefixed by "?".
Improved the configuration library to support list and table properties.
Updated theme for now, to include the feed examples.
Added "cache" classes, to ease caching of html output for instance. (TODO: improve by providing a cache manager).
Comments: minor update.
Updated CMS_NODE_STORAGE_I API.
Delete a node using a node as formal parameter instead of node id.
Clean code and update log information.
Added precondition to delete node to accept nodes with a valid a id.
Added missing assertions tag names.
(instead of specific node/{nid}/add_child/page url)
Fixed implementation of `CMS_NODE_API.is_node_a_parent_of (..)',
and improved parent validity checking against cycle.
- Trash a node now does a soft delete (move to trash container).
- Delete a node now remove it from the storage (no undo).
Signed-off-by: jvelilla <javier.hector@gmail.com>
- Fixed comment.
- added check to know if there are potencial cycles
- added postcondition to ensure the list of potencial parent will not produce a cycle.
CMS_PAGE_NODE_TYPE_WEBFORM_MANAGER.update_node
- Updated code to handle unassing parent from a node when the user
- submit a -1 value.
NODE_FORM_RESPONSE.edit_form_validation
- Added validation for node_parent, check if the input is valid and then
- if exist a valid node in the list of available parents for the current node.
Signed-off-by: jvelilla <javier.hector@gmail.com>
- Add support to create a new node as a child of an existing node.
- Update or add a parent for a given node.
Fix delete and trash behavior: when a node is not published only the
- author or admin see it.
Fix Node and Page node Revisions.
- extracted from populate_recent_changes, the recent_changes_sources that enables to filter early.
Added author_name to the CMS_RECENT_CHANGE_ITEM to support author which is not related to any CMS_USER.
Implemented the simple filtering on source and add parameters size and date.
Added blocks configuration settings via the cms.ini and "blocks" section
ex: [blocks]
navigation.region=sidebar_first
This enables the site to change default block location, and even hides it easily, if the theme does not include associated region name.
Revisited hooks management, and added new CMS_HOOK_MANAGER.
Added admin, and other link into navigation menu that goes into first sidebar.
Fixed theme info, and template for sidebar ids.
Better css class name for cms node content.
Updated node extension implementation.
Updated known permissions for node module.
Improved code for node storage extension , in preparation to code factorization.
Ensured that author is updated when saved.
Added CMS_MODULE.permissions to allow module to declare the potential permissions.
Added support for CMS_LINK.is_forbidden, in relation with CMS_LOCAL_LINK.permission_arguments.
Split link "username (Logout)" into 2 links "username" and "logout".
Fixed/Changed the way auth modules alter the logout link based on "(Logout)" title, by safer solution based on `location' of the link.
Fixed usage of WSF_REQUEST.path_info by using percent_encoded_path_info which is not non unicode path info to be used most of the time.
Merged CMS_REPONSE.variables and CMS_REPONSE.values .
When possible, prefer usage of CMS_RESPONSE.user instead of CMS_REQUEST_UTIL.current_user (WSF_REQUEST) whenever it is possible.
When possible, prefer usage of CMS_RESPONSE.location, rather than usage of WSF_REQUEST.(percent_encoded_)path_info .
Code cleaning.
For now, whenever we save a node, it is marked as published.
Display a node only if published.
Updated /trash page.
Updated /nodes/ page to take into account the node status.
If user is not logged in, show a login option.
Updated New Password
Added option to request a new password using username.
Updated templates to use {$site_url}
Now, all formats used by CMS are instances of CMS_FORMAT, mainly to prepare the admin section in order to define format by config/database.
CMS_NODE_API provides all queries to access the content types, and formats, this way a module can easily alter the formats by adding a new filter.
TODO: see how to integrate permission checking, to control who can use a specific format (such as full HTML).
Updated basic_auth module to handle templates
All the auth modules depends on CMS_AUTHENTICATION_MODULE
Send mail is done using features from CMS_AUTHENTICATION_MODULE.
Update redirect in roc_auth.js after success login to home.
Added CMS_HOOK_RESPONSE_ALTER to give a last chance to alter the response before rendering.
This hook should not be used, when there are other alternative hook that answer the need, but this is proposed for now, as a way to alter response by adding css, js url, ...
Moved blog under official modules folder.
Cleaned theme of demo example project.
Renamed NODE_MODULE as CMS_NODE_MODULE.
Updated code for sql that should not use parameters
to expand :table_name in table name usage,
since Eiffel Store will use quote,
and MySQL does not like them.
Merge remote-tracking branch 'jvelilla/roc_auth_v1' into ewf_v1_mod_env
Conflicts:
examples/demo/demo-safe.ecf
modules/auth/cms_authentication_module.e
Note that CMS_SETUP provides locations set by default or from configuration file.
Now theme related resources can be found under site/modules/$mod_name/... or site/themes/$theme/modules/...
so only theme related resources can be overriden for now.
Now we have ODBC .. that accepts various connection string (including SQLite, MySQL,...)
And EiffelStore+MySQL.
Updated sql scripts to work with MySQL, and SQLite.
Added a sql_statement (s: STRING): STRING that converts ROC sql statement to fit the underlying database engine.
mostly to adapt incompatibilities such as AUTO_INCREMENT for MySQL and AUTOINCREMENT for SQLite
by default SQL script should be written following MySQL SQL syntax.
Warning: to use ODBC persistence driver, it has to be installed on the target machine.
- OAUTH LOGIN: is generic based on a new OAUTH_20_GENERIC_API
- Storage (at the moment only SQL) for OAUTH_CONSUMER configuration.
- OAUTH login and callback are generic.
- Added a OAUTH_20_GENERIC_API.
- Added scripts and templates to build the new OAUTH tables.
- Fixed CMS_STORAGE_SQL_I.check_sql_query_validity issue.
- Extended CMS_STORAGE_SQL_I, to execute scripts with paramerters.
- Updated filter, now it's generic for every OAUTH consumer.
- Updated routes relative to /account/
- Updated emails with template support.
- Updated cookie to support the new route.
- Updated smarty block templates to use the new path.
- Added an API to mange user OAuth authentication.
- Updated the Filter to use the new API.
- Updated the Module to initialize if it needed the storages needed by the login module.
- Updated gmail callback to use the new API.
- Added a Persistence Layer
CMS_USER_API
- clean api and related persistence code.
Added OAuth2 GMAIL loggin/logout support.
Added OAuth2 Gmail filter.
LoginModule
Updated LoginModule with OAuth2 Gmail support.
Persitence
Extended user persitance api with OAuth2 gmail features.
(TODO refactor persistance as an user extention)
-- The module handle basic_auth (at the moment).
-- Handle login, logout, register user, activate/reactivate an account, password recovery.
-- Send notification emails.
CMS Updates
-- Added a new service: email.
-- Updated Basic Auth Module to handle logout based on the browser type.
-- Updated persistence layer to save and remove and query activation token and password token.
-- Updated CMS_USER to handle status {active, not_active, trashed}.
-- Updated MySQL scripts to be in sync with SQLite scripts
Now use CMS_MODULE.is_initialized: BOOLEAN as precondition of many routines.
Instantiation of node storage is now done in NODE_MODULE and not any more in CMS_NODE_API.
CMS_NODE_API can be instantiated only by NODE_MODULE.
Merged CMS_BLOG_CONFIG with CMS_BLOG_API.
In CMS_BLOG_API, prefer argument of type CMS_USER, rather than using directly user id.
Added a CMS_EDITOR_CONTENT_FORMAT for now, to be the format editable by the WYSIWYG editor.
Added CMS_MODULE.is_initialized: BOOLEAN to equip router, and module_api with expected preconditions.
Fixed typo, especially in log output.
Corrected a few routine names such as add_authors that should not be a function according to its name.
Converted various function returning html content, to procedure appending html content to an output string to minimize temporary string object creation.
Cosmetic: added spaces to make code easier to read, and indentation.
#7 and #8: The class CMS_EDITOR generates javascript code that replaces a textarea with a wysiwyg editor. Only a few methods have to be implemented by the subclasses, for example by CMD_EDITOR_CKEDITOR. The class CMS_FORM_TEXTAREA extends WSF_FORM_TEXTAREA with features to include the javascript from CMS_EDITOR. The most complex usage is shown in CMS_NODE_TYPE_WEBFORM_MANAGER, where the textarea is only replaced if "full_html" is selected as the desired body format. This works dynamically on the browser side as soon as the user selects another format.
The blog module routes /blog/{page} and the blog handler limits the entries per page (given as a feature) and sets the offsets according to the given page number
Local paths are relative to cms site url (i.e no starting slash).
Favor CMS_RESPONSE.absolute_url and url .. instead of using directly WSF_REQUEST.absolute_script_url and script_url.
Handled unicode truncation issue for logger.
Code cleaning.
Local paths are relative to cms site url (i.e no starting slash).
Favor CMS_RESPONSE.absolute_url and url .. instead of using directly WSF_REQUEST.absolute_script_url and script_url.
Handled unicode truncation issue for logger.
Code cleaning.
Added Handler to show the current trash nodes for a given user.
An admin can see all the trash nodes.
Updated storage to handle trash and revert nodes.
Refactored CMS_MODULE.router (..): WSF_ROUTER design,
to create only one router object of type CMS_ROUTER.
Added optional CMS_NODE.link: CMS_LOCAL_LINK
Reviewed permissions related to node module.
Refactor and add CMS_STORAGE_SQL(_BUILDER) abstractions
for implementation relying only on SQL statements.
Factorized sql builder initialization (to work for sqlite and mysql storage builders).
Added CMS_RESPONSE.formatted_string (a_text: READABLE_STRING_GENERAL; args: TUPLE): STRING_32
Added function "translation", but not implemented for now.
Updated indexing notes and comments.
Code cleaning.
Updated CMS_NODE_API, with status, not_published, published and trashed.
Updated Form response to use permission scopes.
Updated sqlquery to retrieve user author.
Added logger info in cms_response
Updated CMS_NODE with a new status attribute.
Updated table nodes to support trashing (or soft deletes) of node using the new status field
Updated Sqlite builder to test different scenarios for users and roles.
Updated NODE_FORM_RESPONSE.edit_form feature to add a delete operation
if there is a node ie node id >0 and the current user has delete permission on it.
Updated NODE_HANDLER.do_post to handle the operation "DELETE".
Updated queries to retrieve nodes filter by no logical deleted rows (ie. status is trashed).
Signed-off-by: jvelilla <javier.hector@gmail.com>
Renamed "layout" lib as "app_env" with APPLICATION_ENVIRONMENT interface.
applied changed to callers.
Added CMS_THEME.has_region (a_name): BOOLEAN to know if a region is declared in a defined theme.
Added CMS_NODE_TYPE as descendant of CMS_CONTENT_TYPE,
in case we have content which is not a node in the future.
(probably useless, but for now, this extra abstraction is harmful)
Moved all node related code under node module cluster.
Applied comments from Javier Velilla.
Code cleaning.
but this is an example about on to add a new content type, and support it.
Fixed new node form workflow.
The current state is not final, it requires many changes, but for now, it implements a node editing workflow.
Added support for custom value stored in CMS_STORAGE.
Added optional css classes addition to CMS_BLOCK output.
Refactored storage, to manage node from node module code only (or mostly).
TODO: improved view for a cms node, for now hardcoded.
Implemented role and permission storage.
Introduced the CMS_PARTIAL_NODE and CMS_PARTIAL_USER.
Added support for node storage extension
- storage of data specific to each node content type,
- in addition to the core CMS_NODE)
- For now, only implemented for SQL storage.
Note: in current version, CMS_PAGE support is hard coded in the core,
(as opposed to be only supported by the node module.)
Commented/removed for now, the Web API code to update node summary, title, via REST request.
Added support for ?destination=... so that login or logout will return to previous visited page.
Revisited the sending of generic response such as access denied, unauthorized, redirection ...
Fixed support of CMS_RESPONSE.header which was previously ignored.
Added support for CMS_RESPONSE.redirection: detachable READABLE_STRING_8, to allow easy url redirection.
Added CMS_NODE.make_empty
+ Cosmetic.
Protected cms service from registering many time the same module type.
Moved library/persistence/implementation/* under library/persistence/.
Moved site/www/themes to site/themes
For SQLite storage driver, auto create sqlite db file using associated sql script (to be completed).
Added code in demo module to reuse storage for module purpose.
Always call sql_post_execution in sql_query and sql_change, and not anymore by the callers.
Removed is_web and is_html from {CMS_SETUP}, it was not used.
Reused SHARED_*_ENCODER in CMS_ENCODERS
Added CMS_API.logger rather than using directly the SHARED_LOGGER.log ...
Centralize the implementation of current_user in CMS_REQUEST_UTIL
Removed the inheritance on WSF_FILTER for node handlers, since it is useless and unused.
Added CMS_NODE_API and CMS_USER_API
Prefix html id for block generated html items with "block-", to avoid css name conflict on "main", "content" or similar.
Code cleaning
Simplified schema to focus on user and node.
Now possible to have sqlite via ODBC and/or mysql support, and select using configuration file.
Updated demo example.
Reviewed configuration related feature.
Renamed JSON_CONFIGURATION as APPLICATION_JSON_CONFIGURATION_HELPER to avoid confusion.
Updated CMS_DEFAULT_SETUP to use configuration from cms configuration library.
Added {CMS_API}.module_configuration (a_module_name: READABLE_STRING_GENERAL; a_name: detachable READABLE_STRING_GENERAL): detachable CONFIG_READER to help getting access to configuration of a module (for now, only json and ini are supported, but in the future, this could support database layer directly)
Added CMS_HOOK_BLOCK_HELPER to reuse the template_block (..): ... function.
Cosmetic
Removed CMS_SETUP.smtp_server since for now, there is no need for such general setting.
Add header line "X-ServerEWF-App: CMS" as a simple way to know if request is processed by the CMS.
Added bad_request_error_cms_response
Updated code example to use the new internal_server_error_cms_response instead of error_500_cms_response class.
Removed class error_500_cms_response.
Updated cms setup and configuration design:
Removed CMS_SETUP.configuration: CMS_CONFIGURATION
Removed CMS_CONFIGURATION and replaced it by using the configuration library.
Added CMS_DEFAULT_SETUP.configuration: CONFIG_READER
Addec CMS_SETUP.text_item (name): detachable READABLE_STRING_32 ...
in order to access option not publish by the CMS_SETUP interface.
Removed CMS_SERVICE.configuration: CMS_CONFIGURATION since it was not used.
Moved configuration library from eiffel-lang to cms libraries.
Fixed issue related to ini config when parsing from string content,
and also issue related to section included in file via @include.
Updated cms setup and configuration design:
Removed CMS_SETUP.configuration: CMS_CONFIGURATION
Removed CMS_CONFIGURATION and replaced it by using the configuration library.
Added CMS_DEFAULT_SETUP.configuration: CONFIG_READER
Addec CMS_SETUP.text_item (name): detachable READABLE_STRING_32 ...
in order to access option not publish by the CMS_SETUP interface.
Removed CMS_SERVICE.configuration: CMS_CONFIGURATION since it was not used.
Improved the email service and related.
Updated CMS_API, added wrapper features to access error_handler. has_error, reset, as_string_representation, hide
the actual error hanlder implementation.
Updated Error Filter with better logging.
Added CMS_RESPONSE.module_assets_location and CMS_RESPONSE.module_assets_theme_location
that help locating module related assets.
Added CMS_BLOCK.is_raw to abstract CMS_CONTENT_BLOCK.is_raw
**ROC CMS** stands for "REST On CMS", however, until now, no particular focus was done on the REST API approach, and so far a more pragmatic approach dominated.
Part of the design is inspired by Drupal (blocks, hooks, Role-based access control, ...), and other parts related to Eiffel. Priorities, modules and related have been driven by concrete need, in order to fulfill the https://eiffel.org/ websites. Also a contribution (as student projects, or others) helped build various modules or functionality.
Currently, **ROC CMS** is a library or **framework** that provides components, tools and resources to build a CMS (Content Management System). It is not currently a CMS product, one can install and customize without any code.
Thus, it will be interesting for people willing to build a website using **Eiffel**. This will enable to reuse other Eiffel components, better integration with other Eiffel projects, and of course benefit from all the goodies of the Eiffel technologies (Eiffel language, DbC, re-usability, portability, IDE, debugger,...).
It depends on the **Eiffel Web Framework** (known as "Eiffel Web" or "EWF"), and thus can be executed as standalone, or CGI, libFCGI mode on Apache2 for instance, and on any Windows or Linux platform).
The main notions are:
- CMS Execution
- CMS APIs
- CMS Response
- CMS Modules
- CMS Hooks
- CMS Theme, blocks, links, ...
Those points will be described later in appropriated sections.
## Setup
The ROC CMS source is available either with the latest EiffelStudio release under the locations:
- $ISE_LIBRARY\unstable\library\web\cms
- or from github project https://github.com/EiffelWebFramework/ROC branch v0 for now.
Note that if you use the source code from the github repository, you will need to use the latest release of EiffelStudio as it relieѕ on recent version of various libraries such as EWF, sqlite3, ....
And using the "master" branch, even the trunk version of EiffelStudio libraries. So for now, we encourage you to use the ROC CMS shipped with your EiffelStudio.
Once you have the source code, you should compile project <code>cms/example/demo/demo-safe.ecf</code> target "demo_standalone".
# or launch EiffelStudio, and open that project, compile and execute it inside the debugger for instance.
````
This demo includes all the official ROC CMS modules, files, and use libsqlite3 as default storage engine. So you should be able to execute it easily. The **standalone** target is configured to listen on port 9090 by default. (Mostly to avoid conflict on other app that my listen on port 80 or 8080).
In the directory <code>site</code> you will find all the expected files that should be in the root directory.
* config/ : it contains the various configuration files, especially the **cms.ini**.
* modules/ : files associated with each installed ROC CMS module.
* scripts/ : common scripts used mainly to initialize SQL databases.
* themes/ : folder containing the available ROC CMS themes.
* files/ : folder containing files available from the ROC CMS app.
* And also demo.ini that contains the settings for the web launcher, (in our case, the standalone Eiffel server), such as port_number.
Now that you know how to compile, execute, and see the related configuration files, let's describes the main notions of the ROC CMS, first from
* an admin point of view (dev using ROC CMS to build its site),
* and then from a developer point of view (in case you want to contribute to ROC CMS).
## Usage
### Main entries
As a CMS administrator, you will need to setup your CMS application (here the demo example). For this purpose, the main entry points are the CMS_EXECUTION interface, and then the <code>site/</code> files (configuration, themes, templates, ...).
### CMS initialization/Execution
The `CMS_EXECUTION` interface is deferred, and your CMS application needs to inherit from it and define `setup_storage`, `initial_cms_setup` and `setup_modules`. See for instance `DEMO_CMS_EXECUTION`.
So, the descendant of `CMS_EXECUTION` (`DEMO_CMS_EXECUTION` in the example), is creating the `CMS_SETUP`, declares the available **storage** builders (for persistency), and declares the available **modules**.
#### Persistence/Storage
Depending on the **configuration**, the CMS engine will instantiate and use a specific **CMS_STORAGE** (the default is based on `Eiffel sqlite3`, otherwise `EiffelStore+MySQL` and `EiffelStore+ODBC` are available). The storage solution is used to implement the persistence layer, and thus store and load CMS data to disk, or database.
The CMS provides, for now, storage based on
* EiffelStore + MySQL
* EiffelStore + ODBC (could be used for MySQL, sqlite, SQLserver, ...)
* Eiffel sqlite3 : that one is the default storage, since it is convenient for testing, but it is recommended to use EiffelStore+MySQL in production CMS site.
A typical implementation of <code>setup_storage</code> is:
And the CMS decides which storage should be used. It depends on the application configuration. See the **configuration** section.
Those data could be user information (login, email, password, ...), custom values, logs, emails, path aliases, ... and any data modules may need to store (for instance node content, for the `node` module.)
#### Modules
The `setup_module` is used to declare available **modules** (instances of `CMS_MODULE` effective types).
The modular design provides a simple way to extend or alter the CMS functionalities/behaviors.
Most of the CMS features are implemented by modules, and each module relies on the core of the CMS core.
This **core** contains the `CMS_API`, `CMS_USER_API`, and various internal mechanisms such as mailer, logger, ...
Use `setup_module (a_setup: CMS_SETUP)` to customize the `CMS_SETUP` object created by `initial_cms_setup`.
For your convenience, ROC CMS provides a `CMS_DEFAULT_SETUP` that import configuration from `site/config/cms.ini`
So far, what you need to remember is `CMS_EXECUTION` class and descendants are used to set up the ROC CMS application, for storage, modules, and also how to load configuration.
Note that a module can have 3 states:
- not installed,
- installed and enabled,
- installed and disabled.
At first, to install the modules, open your browser at location `https://hostname:port/admin/install` and click the associated button.
(Note: for new module addition, you also need to install them, using the same link, in the future, there will be a proper module management interface, in the admin front-end.)
To enable or disable a module, you will need to use the `cms.ini` configuration file, please see the **configuration** section.
Existing modules:
- **admin**: basic administration pages, to manage modules, roles, permissions, users, caches, ... (note: it is still very basic, and need effort to improve it.)
- authentication modules based on **auth**:
- **basic_auth**: account signing using basic HTTP Authorization solution
- **oauth20**: sign using a thirdparty OAuth2.0 account (such as Google, Facebook, github, ...)
- **openid**: sign using an OpenID account.
- **node**: the base of node management, include **Page** content type.
- **blog**: extends the **node** module with a **blog** content type.
- **recent_changes**: compute recent changes of CMS (integration with **node** management, and any modules that implement the `CMS_RECENT_CHANGES_HOOK`).
- **feed_aggregator**: aggregate one or many feeds (rss, atom, ...), and provide associated pages or blocks.
- **google_search**: provides search facilities using the Google Custom Search API.
### Configuration
When `CMS_DEFAULT_SETUP` is used, the CMS configuration is loaded from `site/config/cms.ini`.
That file contains a few sections:
- **site**: to set the `name`, `email` and the name of the `theme`. (See "Themes" section pour information.)
- **layout**: the application layout (or environment) can precise the `root-dir`, `themes-dir`, `modules-dir`. If not defined, the values are computed from Current working directory.
- **mailer**: the CMS can send email notification for various reasons, such as new users, or reset password functionalities, ... In this section, you can use
-`smtp` settings to precise an SMTP server (+ port),
- or `sendmail` to use an external script using the sendmail usage,
- or just an `output` file such as @stderr, or a path to a file on disk.
- **modules**: used to enable or disable modules.
-`*=on` -> modules are enabled by default
-`*=off` -> modules are disabled by default
- Note the default value is `on`
- For each module, this can be overwritten with `module_name=on|off`
- **blocks**: settings for blocks (See Themes, Blocks sections for more information on the block). A few parameters are available to customize blocks. The general form is `block-name.param=value` (note that "foo.bar" is a value block name.)
-`block-name.region`: assign the block `block-name` to a specific region. A block can be assigned to **only one region**.
-`block-name.title`: used to overwrite the block title (with <none> , the title is hidden).
-`block-name.weight`: used to order blocks in the same region (blocks with lower weight goes first).
-`block-name.expiration`: used to provide a basic cache system based on expiration. The value is a number of seconds before the cache expires (-1: never expires, 0: never cache, n: cache expires after `n` seconds).
-`block-name.condition`, or `block-name.conditions[]`: include `block-name` only under specific condition(s). The condition can be
-`is_front`: which is True only for the front page, usually at url "/"
-`path:foo/bar`, `path:foo/*/bar`: True only for CMS location matching the patterns after "path:"
-`<none>`: related block is disabled.
- *note: There can be multiple conditions processed as any of the conditions (i.e: "or").*
-`block-name.options[varname]: pass a table of options `varname => value` to the related block. This can be used to pass parameters for block builder (for instance, recent_changes modules accept parameters "size" to know how many changes should be included.)
- To be able to include a block content into multiple region, it is possible to use aliases feature. For instance `&aliases[new_block]=block-name`, in this case, a `new_block` is declared, and it has same content as `block-name`, on this alias, the parameters `region, condition(s), title, weight` are supported, but not `options[]`.
- **admin**: various admin related settings such as
-`installation_access` which accepts 3 values: "all", "none" or "permission", to precise who has access to the modules installation page; either "all" for anyone, "none" to disable installation of new modules, or "permission" to use the CMS permissions solution to determine if the current user can install a new module.
Then, the configuration `cms.ini` can also define other parameters, and sections, that may be used by specific modules.
Note it is also possible to include another ini file with instruction `@include=path-to-file.ini`.
Check the `example/demo/site/cms.ini` for example.
### User management
The CMS core includes the notion of user, via interface `CMS_USER`, which has an id, a name, a password, ... and profile. Without any module, the CMS does not include any mean to authenticate, but still the CMS has the support for user management, and permissions system for current user. To be able to sign into the CMS, the site should include the module `auth`, and one or many of:
-`basic_auth`: authentication using the HTTP Authorization header.
-`oauth20`: being able to sign with an OAuth2.0 account (such as Google, Facebook, ...)
-`OpenID`: being able to sign with an OpenID account.
Whatever authentication solution is used, when a user is signed-in, there is an instance of `CMS_USER` representing the associated CMS user account.
There is a predefined user `admin` who is the administrator of the CMS, and by definition, this **admin** has all the permissions. It is initialized by default with username `admin` and password `istrator#`.
The access control is role-based permissions system. This means, a user can have one or many *roles*, and each *role* includes a list of *permissions*.
There are two built-in roles:
- **anonymous**: when no user is signed in (typically anonymous visitors).
- **authenticated**: when a user is signed in the CMS.
With those 2 built-ins roles, and any custom role the admin will create, it is possible to give specific permissions, to a group of users.
The CMS core defines a few permissions, and each module can also define their own permissions, for instance: "view any page", "create page", "edit page", "delete page", "clear cache", "install modules", ... (when the administrator is signed-in, go to url `/admin/role/1/edit` to see all the available permissions).
### Modules
A module is the way to extend the CMS engine.
First via the inherited `CMS_MODULE` interface that enables a module to:
- have a custom `install` and `uninstall` procedure by redefining the related routines.
- add its **routes** via `setup_router`. (i.e associated url or template of url with a specific request handler).
- register itself to hooks via `register_hooks`.
- declare new permissions by redefining `permissions`.
- provide a specific module api by redefining `module_api`.
- add its **filters** by redefining `filters`.
Using the `hooks` system, a module can be deeply integrated with the CMS engine, and even alter behaviors (for instance, add link, add css, javascript, ...). See related developer documentation on hooks.
It is simple to create your own modules (check the developer documentation).
The ROC CMS library provides a few modules for now, for instance: basic_auth, oauth20, openid, node, blog, feed_aggregator, recent_changes, google_search, ... and others (the list keeps growing...).
**Reminder**: to include a module to your CMS site, you need to
- include the associated .ecf file in your CMS site .ecf file.
- and also declare them in your descendant of CMS_EXECUTION.
- copy the eventual resources, configuration, ... files in the corresponding `site`.
Note: a tool **roc** is under development to ease such operations, for now it only copies needed files from module to site location. In the future, it should also update .ecf files, associated CMS_EXECUTION effective class.
### Themes
When talking about CMS, a major topic is how a request is rendered in a web browser. Here comes the notion of **theme** which is a collection of templates, accepting various values as input (including the content of the blocks), and renders as an html5 page. It also includes various assets such as css, javascript, icons, images, ...
The ROC CMS theming is inspired by Drupal, with the notion of **region** and **block**.
Note: for now, there is no simple "theme" module or similar, and the common way to start your CMS site is to copy an existing project such as the one available with the demo example (i.e: copying the source code, but also the `site` folder).
Currently the default theme of the demo example `SMARTY_CMS_THEME` is based on Eiffel **smarty** template library (Check [smarty doc](https://svn.eiffel.com/eiffelstudio/trunk/Src/contrib/library/text/template/smarty/README.md) for syntax and functionalities).
The layout of a CMS web page has predefined area called **regions**. The Eiffel CMS uses the same default regions as Drupal, so let's see them in the following image.
The regions available for a theme, are defined in a configuration file `theme.info` located in the theme directory. For example:
```
name=default_theme
engine=smarty
version=0.1
regions[page_top] = Top
regions[header] = Header
regions[content] = Content
regions[highlighted] = Highlighted
regions[help] = Help
regions[footer] = Footer
regions[sidebar_first] = first sidebar
regions[sidebar_second] = second sidebar
regions[page_bottom] = Bottom
```
Note: the value for each region is the human readable region name.
Note the regions may be disposed with other layout (two sidebars on the left, or right, ... and so on), responsive design or not, and so on. But on the CMS side, a *block* can be inserted into a *region*, and depending if the region is included in the theme, the related block content will be displayed or not.
To sort *block* inside a region, the CMS is using the `weight` property (that can be set via code, and/or overridden via configuration, i.e: `cms.ini`).
This is how a site can support many themes, using the region as content holders, and theme for the layout and style.
Internally the block contents are stored in the values associated with each region.
The theme also has access to specific `values` such as
-`site_url`: the absolute url of the CMS website.
-`host`: the host name.
-`is_https`: True if the connection is using https://
-`user`: contains the username of the signed user, if any.
-`site_title`: site title.
-`page_title`: per page title.
- and also `page: CMS_HTML_PAGE` which represents the CMS page to render with the theme.
-`page` provides values via expression, such as `$page.type`, `$page.is_front`, `$page.is_https`, `$page.title`, ...
- and also a smart expression for region via `$page.region_xyz` for region `xyz` if any, ... (note the region are also available with expression like `$region_xyz` or `$page.region_xyz` ...)
==Note for developers: internally, the deferred class `CMS_RESPONSE` provides an abstraction to render the response for the request using the **theme**, in fact, the theme is controlled by the CMS_RESPONSE implementation (to set value, build expected theme, and finally render as html).==
### Blocks
As previously said, a region holds smaller piece of content called blocks.
Blocks hold chunks of content, like the user login form, navigation menu, information for the footer, or anything provided by each module.
For instance the `feed_aggregator` module provides a block to display the latest elements of a aggregated feed.
Currently there are different kind of `CMS_BLOCK`:
-`CMS_CONTENT_BLOCK`: it holds a simple text to render as it is on the page.
-`CMS_MENU_BLOCK`: it holds a `CMS_MENU` as a collection of `CMS_LINK` generally used to hold a menu, or set of links such as navigation or management menus.
-`CMS_SMARTY_TEMPLATE_BLOCK`: it holds a simple text to render as it is in the page.
Internally, there are two other kinds of block:
-`CMS_ALIAS_BLOCK`: being the alias of another block, but with specific properties.
-`CMS_CACHE_BLOCK`: there is a simple cache solution for blocks, based on expiration. See the configuration section to know how to define the expiration for a block.
For now, creating a block is only possible via block, an evolution of ROC CMS should allow the administrator to add new block without coding.
### Persistence
The persistence or storage layer is used by the CMS to store custom values, path aliases, logs, emails, user information, but it is also used by module (unless a module wants to use its own persistence solution, disk, cloud, ...).
Currently, there are only SQL based implementations of that `CMS_STORAGE`, but nothing prevents to implement it with other solutions (plain text file, NoSQL db, ...).
The current implementation are using either:
- EiffelStore + MySQL: recommended for production, however Eiffel MySQL requires to configure your environment by setting, for instance MYSQL variable on Windows, and MYSQLINC on Linux.
- EiffelStore + ODBC: via ODBC, there is a large range of available database (MySQL, SQLite, SQLserver, ...), but it requires to set up your environment (for instance install sqliteODBC driver to use SQLite database).
- Eiffel sqlite3 wrapper: it is very convenient for development, but maybe not recommended for production websites. It does not require any environment setup, so this is a simple solution to build tests for instance.
In practice, how to use a storage or another?
The project needs to include the expected storage, the following instructions explains how to include sqlite3, EiffelStore+ODBC and EiffelStore+MYSQL storage.
1. First the associated .ecf file need to be included in your project file (.ecf)
3. And finally, in the configuration file `site/config/demo.json` (in fact, the executable name + ".json"), define the driver and environment of the datasource. For instance the following code defines **sqlite3** as default CMS storage, and environment *sqlite3* that defines the path of SQLite database as "site/database.sqlite3". Note the way to declare sqlite with ODBC, mysql with ODBC, or mysql directly with EiffelStore.
To use EiffelStore+MySQL, just change the "driver" to be "mysql" and "environment" to "mysql". The connection string for server database defines the credentials with "Uid" and "Pwd".
### How to run the CMS site?
As any Eiffel Web application (EWF), it can be executed as
- **standalone**: using Eiffel standalone httpd server included in the "standalone" connector, and then no setup is needed.
- **CGI** or **libFCGI** server: using, for instance, Apache2. Please refer to the Eiffel Web Framework documentation.
### Conclusion
At this point, you know enough to build and administrate a ROC CMS site.
However, for a real site, it is likely that you will need to build your own modules, you will learn how doing that in the Developer Documentation.
***
## Developper Documentation
This diagram shows the main interfaces, they will be described in this documentation, but for now, it introduces those class names.

### CMS APIs
An instance of CMS_API is available either via argument, or via attribute / function of various CMS components.
It provides routine specific to the ROC CMS engine (access to setup, modules, logs, custom values, ...).
### CMS Hooks
Hooks is a mechanism which provides a way for modules to interact with each other and extending blocks of the current CMS.
- [CMS_HOOK](../library/src/hooks/cms_hook.e): deferred class CMS_HOOK is a marker interface for CMS Hook
- [CMS_HOOK_AUTO_REGISTER](../library/src/hooks/cms_hook_auto_register.e): when inheriting from this deferred class, the declared hooks are automatically registered (note only the CMS core hooks are supported, as opposed to hook a module may propose). Otherwise, each descendant has to register itself to the associated hook manager.
- [CMS_HOOK_BLOCK](../library/src/hooks/cms_hook_block.e): it provides a way to declare and build blocks.
- [CMS_HOOK_FORM_ALTER](../library/src/hooks/cms_hook_form_alter.e): it provides a way to alter a web form `CMS_FORM`.
- [CMS_HOOK_MENU_ALTER](../library/src/hooks/cms_hook_menu_alter.e): it provides a way to alter a menu, and thus add or remove a link. This is how a module can add a link into a specific `CMS_MENU`.
- [CMS_HOOK_MENU_SYSTEM_ALTER](../library/src/hooks/cms_hook_menu_system_alter.e): similar to CMS_HOOK_MENU_ALTER, but on built-in menu, such as management, navigation menus, and other.
- [CMS_HOOK_VALUE_TABLE_ALTER](../library/src/hooks/cms_hook_value_table_alter.e): it provides a way to alter the values table for a response (i.e: inserting custom values, or even override existing values).
- [CMS_HOOK_EXPORT](../library/src/hooks/cms_hook_export.e): it provides a simple export solution for each module. Typically used to archive data associated with a module, for instance for backup purpose. In the future, a `CMS_HOOK_IMPORT` should also be available, and it would allow importing data exported by `CMS_HOOK_EXPORT`.
- and for more hooks ... please check descendants of `CMS_HOOK`.
### Custom Module
How to build a new module?
A module is usually developed as an Eiffel library, and provide one or many implementations of `CMS_MODULE`.
It has to set or implement:
- **name**: a unique name identifying the module
- **description**: a human text to describe the purpose of the module, it will mainly be used by the administration front-end.
- **package**: put the current module into a package, mainly for admin front-end.
- **version**: version information
- **dependencies**: defines dependencies on other modules.
- **permissions**: defines permissions used by the modules (mainly for admin front-end)
- **setup_router**: associate routes with request handlers (declare various url or url template and associated request handler).
- **filters**: similar to routers setup, but for WSF Filters (See EWF documentation for more details).
- **register_hooks**: register current module with various hooks if needed.
A module can also redefine `install` and `uninstall`. This could be used during installation to create new database tables, or anything needed by the module, or clean similar resources when being uninstalled.
In addition, a module can also implement `module_api: detachable CMS_MODULE_API` in order to be integrated easily with other modules (see for instance the CMS_NODE_API defined in **node** module).
Please have a look at the [tutorial](tutorial.md) page.
## References
For the interface references, please have a look at the [ROC CMS source code](https://github.com/EiffelWebFramework/ROC).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.