bombayworks / currycms

Curry CMS is an open-source Content Management System (CMS) for PHP 5.3.

Curry CMS

Curry CMS is an open-source Content Management System (CMS) for PHP 5.3.

Requirements

• PHP 5.3.7 or later, with the DOM/libxml2 and PDO extension.
• A supported database (MySQL, MS SQL Server, PostgreSQL, SQLite, Oracle)
• Web server with support for URL rewriting

Getting started

To setup Curry CMS, you need a project with some minimal configuration. A project skeleton can be found in the currycms-project-base repository. You can use composer to create a new project using this repository.

• Install composer
• Create project skeleton and install dependencies php composer.phar create-project --stability=dev bombayworks/currycms-project-base <directory>

Once everything has been installed, you need to make the www folder accessible from your web server and configure URL rewriting, after that you should be able to access the project installation from /admin/.

Unit testing

Curry CMS uses PHPUnit for unit testing. In order to run the tests, you need to:

• Download composer development dependencies php composer.phar install --dev.
• Configure database settings in test/fixtures/propel/propel.xml.
• Build propel files for fixtures ./vendor/bin/propel-gen test/fixtures/propel/ main.
• Clear database ./vendor/bin/propel-gen test/fixtures/propel/ insert-sql.
• Run tests: ./vendor/bin/phpunit.

License

See the LICENSE.txt file.

currycms's Issues

Feature Request: Create a better role/permission/privileges management system.

Please improve the role/permission system.
How about using Zend_Acl: http://framework.zend.com/manual/1.12/en/zend.acl.introduction.html

This package also seems good but has a host of goodies, i.e. a whole authorization system too.
https://cartalyst.com/manual/sentinel/2.0#permissions
I used ver 1.0 on laravel 4 and it works quite well.

Your opinions?

Project paths naming standardization

It seems a more common naming convention would be the following:

• Rename cms/ to app/
• Rename cms/include/ to app/src/
• Rename www/ to web/ or public/

I also think, moving propel class files into the app/src/ would be preferable.

Package manager does not upgrade an installed package

PLEASE IGNORE THIS ISSUE IF YOU ARE SWITCHING TO COMPOSER OR ANOTHER PACKAGE MANAGER.

Package manager reports "This package is already installed and is the latest version or newer." when trying to Upgrade an already installed package.

Currently, package must be uninstalled and re-installed to do an upgrade.

Remove famfamfam icons

Famfamfam icons (shared/images/icons) contain almost 1500 files and should be replaced with fontawesome. They are still being used by filebrowser and flexigrid backends.

Use namespaces

We've already had a minimum requirement of php 5.3 for a while, so switching to real namespaces instead of namespacing using the class name should be ok.

While it will break BC, it also has a few upsides; propel model classes will get namespaced which will avoid conflicts with phing etc.

Replace custom package manager with Composer

The custom package manager is not that great, and I think we should replace it with composer.

One problem with this approach is that each composer package should reside in its own folder, and the packages will contain propel schema files. However, propel needs the schema files to be in one folder. I think this can be worked around, not yet sure how.

We should also consider support for theme packages #5.

No vertical inheritance for module content when a Page template is applied to a page.

When a Page template (a.k.a Layout page) is applied to a page, the modules inherit content from the applied layout page and not from the parent pages in the vertical page tree.
This makes it difficult to edit content of a module on a "parent" page (which has an applied layout page) since this content will not be inherited to any of it's subpages (i.e. no vertical inheritance). A module on a child/sub page will inherit content from its applied layout page (i.e. lateral inheritance) and not from the parent page. This is a major issue that needs to be resolved.
However, If a module is created on a page and it's content edited, this content will become available to it's "direct" descendants (i.e. direct vertical inheritance exists).

This looks like a design flaw. Can I propose a new design to tackle this issue? You need to debate it.
A page should not inherit content from Layout pages. A layout page should be a template that specifies, what twig template to use and which modules to insert in the placeholders. It can use the module order but not the content. Content should be created either on the page or should come from the parent page(s).

Bug in Translations module

Cannot clear the value of a field in the Translations module. Need to manually delete the data from the LanguageStringTranslation table.

Set the font for Live edit button in frontend

Font for live edit button should be fixed to 'Arial' so that it is not governed by project's font.

Feature Request: Collapsible SubForms (Fieldsets) in MultiForms

Feature request

1. This should have - Allowing MultiForm Fieldsets (Like accordion, plus/minus) to be collapsible, and pushing the "Delete" on the right or somewhere.
2. This would be good to have - Allowing Fieldsets around form elements added in DisplayGroups to be collapsible if said to be.

Both were faced mostly in Page Modules, where each subForm have a lot of data, and all elements are open always taking lot of space to scroll.

Screendump: https://db.tt/4oiwEYiQ

Use framework for HTTP request and response

Currently http request / routing / response is handled by custom classes, this makes it difficult to integrate with other frameworks. We're also re-inventing the wheel. Why not use existing frameworks that does this very well? I think the one with most traction currently is Symfony's HttpKernel, but there's also ZF2 zend/http, which also would make sense since we use many ZF components. Another option would be to make it pluggable, not sure how easily that can be done though.

A part of this includes rewriting backend modules to use the framework instead of native php $_GET, $_POST, header() etc for request/response.

This would also make testing easier.

Feature Request: Reset permissions button required on Page Permissions tab.

Request to add a reset permissions button on the page permissions form if current user has permissions to alter existing permissions. Furthermore, only the current user's role or user permissions (whichever you think best, maybe user only) for current page should be reset - not all permissions.
This is a safer way to reset permissions rather than altering them directly in the database.

Change development mail redirection

Currently with developmentMode enabled, all mails sent through Curry_Mail will be redirected to adminEmail. This is a bit unexpected and confusing, I think we should keep the functionality but change this to a separate setting.

Theming support

Adding support for themes will make it easier to get started with currycms, especially for non-developers.

A good start would be to use multiple paths with twigs filesystem loader, so it will select files from a template directory if they exist, or otherwise the base template directory.

We also need to make it possible to package templates, including the following:

• Twig template files
• Javascript / Stylesheets
• Images
• Readme / configuration?

An idea would also be to try to define a basic set of block names / placeholders, so themes would use the same naming conventions. This would mean you could switch templates without changing module placement.

Eventually, it would be nice to allow user to control css settings (colors, font, etc) and template variables (such as slogan, logotype image, etc).

Improve default error_reporting setting

Error reporting can be set in config.php, the current default is E_ALL ^ E_NOTICE. This will not include E_NOTICE nor E_STRICT for php 5.3. My suggestion is to set the following defaults:

• developmentMode=true: E_ALL | E_STRICT
• developmentMode=false: E_ALL & ~(E_NOTICE | E_STRICT)

This would show all errors when in development mode and all but E_NOTICE and E_STRICT when not in development mode.

Restructure backend javascript libraries

I recommend we create a build script to combine and compress libraries in shared/libs.

• Use a package manager to download dependencies (bower)
• Use a build script to combine and compress (Grunt)
• Only version control bower.json and build output.
• Remove jquery-ui dependency (currently only used for datepicker and sortables?).
• Remove custom $.require loader, load all libraries instead.

This will reduce the amount of 3rd party files in currycms repository, and hopefully github will see the repository as a php project :) I also think loading all libraries instead of loading them on demand will make backend slighty more responsive.

[Bug] Base URL is Incorrect on Localhost

When running curry with php's inbuilt server, base url is incorrectly set as http://localhost:5102:5102/.

Port number is repeated twice.

A field added to a frontend module after the module is attached with a page does not reflect.

A field (protected variable) added to a frontend module after it is attached with a page does not reflect the content. I did a DB cleanup and cleared cache too. No effect.
I had to remove the module and insert it again into the page.
I think this was fixed in Ucms?

How to Install Curry CMS

How to Install Curry CMS ??
or
link of installation docs

Unify name for live edit / inline admin

Live edit is called InlineAdmin in code. I think Live edit is a better name, we should update code to use only one name.

Upgrade to Zend Framework 2

ZF1 is very heavy-weight and only comes in a big bundle. It is also getting a bit outdated and not getting much attention. Most of the components exist as ZF2 packages. Upgrading will break BC, but hopefully it shouldn't be too difficult.

These are the major ZF1 components currently used by Curry CMS core today:

• Zend_Cache
• Zend_Config
• Zend_Form
• Zend_Json
• Zend_Locale
• Zend_Log - Replaced with monolog
• Zend_Search
• Zend_Session
• Zend_Mail

Translations / Langcode

Feature request:

1. Would like to see the LangCode used for languages in translations for quick access. (Screenshot below)
2. If the site uses/has multiple languages, could have a Default Language

Screenshot::1

Remove symlink dependencies

Since windows doesn't really support symlinks, we should avoid using symlinks within curry. Here's a list of all the symlinks used within a curry project:

• www/shared => ../curry/shared
• curry => vendor/bombayworks/currycms
• cms/propel/core.schema.xml => ../../curry/propel/core.schema.xml
• cms/propel/inject/core => ../../../curry/propel/inject/core

For the shared folder, we can probably get around it using routing; either in webserver config, or using index.php.

As for the curry symlink, I think it can be replaced with basePath from config.

The schema file is a bit more difficult, we could either copy it to propel directory during setup, but it would also need to be updated when upgrading currycms (or when rebuilding?).

Inject folder can probably be fixed by modifying the inject behavior.