Things it should have

[nils-werner]

Just a list of things I think Next (and the framework it is based on) should have. Feel free to append anything you think is important

• PSR-0 compliance
• composer.phar package
• ORM
• Ability to swap out the templating layer
• Builtin DB migrations
• Command Line Tool
• PHPunit/TravisCI integration

Granted, those are all features I've seen in Laravel. I am just blown away by the possibilities they offer.

[iwyg]

Agreed,

furthermore, things that should be considered:

• scalability
• easy to use with reverse proxies
• solid approach on user handling (think of ACL)
• RESTful architecture
• Nice to have: AOP // that's actually just a personal dream :)

Am 13.04.2013 um 11:19 schrieb Nils Werner [email protected]:

Just a list of things I think Next (and the framework it is based on) should have. Feel free to append anything you think is important

PSR-0 compliance
composer.phar package
ORM
Ability to swap out the templating layer
Builtin DB migrations
—
Reply to this email directly or view it on GitHub.

[michael-e]

We should finally drop the current technical separation between the frontend and the backend. Which means to still have a backend, but:

• use Members and an ACL to manage access to the backend (because having two different types of accounts seems strange)
• generate the backend with datasources, events, XML and XSLT (resp. correspondent core concepts of Next)

This would mean having one account for everything. Another advantage would be that backend code can be re-used by developers to build "interaction" in the frontend.

I have built a rather advanced administration area in my web app's frontend, so I know what I am talking about. Maybe — depending on a major rewrite of my own utilities — I could contribute XSLT code to auto-generate publishing forms, including field-level validation. This layer should be super-elegant in the end, so it won't be a simple task. But it might be a killer feature if the provided XSLT code could be used in the backend and in the frontend, simply because HTML forms are the pest, and validating data is even worse. So, add another point:

• provide a re-usable XSLT template layer for any kind of "publishing", i.e. forms.

By writing this layer in XSLT exclusively we would follow @nilshoerrmann's proposal from the forum, making XSLT the "pro choice" for the frontend and the sole backend template language. I like this proposal.

[designermonkey]

RESTful architecture

@iwyg I'm so glad you said that, excited even. I've been drafting my version of a proposal for a couple of days, and that word, REST, features very heavily in it.

[nilshoerrmann]

I'd like to second Michael's proposal to consider the administration area just another frontend of a site. This would also make the backend a blueprint for complex web apps that could use Symphony as a starting point for their own service.

Using Symphony to build Symphony will also make sure that the API is tested and working and not lacking features as it currently does. In this context, we should make sure that the visual interface is representing all functions available in the API. As a designer, I don't want to leave the UI and touch PHP files (something you even have to do for simple negations in Data Sources right now).

Furthermore, we should consolidate fields. I hate the concept of "core extensions". We are either dealing with the core or with extensions - there is no middle ground. Things considered essential should be part of the core itself, the rest should not be bundled with a release. From my experience, "core extension" fixes have only landed short before a Symphony release or even required a Symphony beta to work, so we should not make things harder by separating stuff. We should rethink the most essential fields and make sure they share the same settings (requirements, uniqueness, multiple values). The core field's UI should be kept simple but not dumb. Symphony 1.7 bundled a really simple, really nice calendar - I did never understand why it was dropped because it ensured valid dates. We really should look at some lovely ideas that existed in earlier versions.

Ah and finally, to not look stupid here, we should make sure to base everything on ROTFL and WTF to make things more ROLEEYESful.

[nilshoerrmann]

Addendum: Regarding the interface, we should make sure to not reinvent the wheel. The should have a look at existing JS plugins and professional web app libraries like backbone.js and the like.

[designermonkey]

We already have an interface, so we should use the same markup, js and css to save time for the first release IMO.

[nilshoerrmann]

It would save us a lot of time thinking about the UI organisation now and not later. Symphony 2.3 is quite messy due to compatibility decisions. It would not steal us any time by the way because those working on the UI are not the ones working on the underlying PHP core.

[michael-e]

We already have an interface, so we should use the same markup, js and css to save time

Nope. I am with Nils here: Do it right if you get the chance.

[designermonkey]

I'm sorry, I don't understand. What compatibility issues were there? We dropped support for older IE in 2.3, so I thought all of the issues were taken care of?

[nilshoerrmann]

We have left a lot of things the way they were in order to keep extensions up and running. Think about Duplicators, localisations etc. The way we handle backend views in admin.js is not very professional.

[nilshoerrmann]

By the way, rewriting the backend in a new envirinment is a great moment to think about a few essential interactions: Do we really need a dedicated section editor or couldn't this be better handled inline, within the content area? Why do I have to reorder a table to change the backend navigation and navigation groups, if I also could do editing in the navigation directly?

[iwyg]

Agreed.

Am 14.04.2013 um 12:36 schrieb michael-e [email protected]:

We already have an interface, so we should use the same markup, js and css to save time

Nope. I am with Nils here: Do it right if you get the chance.

—
Reply to this email directly or view it on GitHub.

[iwyg]

Maybe a bit premature, but building the backend UI on a Javascript MVC framework could save a lot of time and effort.
A RESTful application architecture (think of laravel's Resource controller) would give us the tools at hand to do so.

This also may drop the necessity for a dedicated templating language for the backend since all or most rendering would be client side.

Am 14.04.2013 um 13:05 schrieb Nils Hörrmann [email protected]:

By the way, rewriting the backend in a new envirinment is a great moment to think about a few essential interactions: Do we really need a dedicated section editor or couldn't this be better handled inline, within the content area? Why do I have to reorder a table to change the backend navigation and navigation groups, if I also could do editing in the navigation directly?

—
Reply to this email directly or view it on GitHub.

[michael-e]

But this would make @nilshoerrmann's (and my) arguments useless:

This would also make the backend a blueprint for complex web apps that could use Symphony as a starting point for their own service.

Using Symphony to build Symphony will also make sure that the API is tested and working and not lacking features as it currently does.

Both would be a big plus.

[nilshoerrmann]

I'm not a fan of building the backend using JavaScript only.

[DavidOliver]

+1 for a fresh start with the backend interface. I imagine there will potentially be quite a few fairly fundamental changes made in underlying functionality/approach, such as the one @nilshoerrmann outlined, and we don't want to have to worry about fitting in with a previous version's markup structure, CSS and JS. There may also be improvements/changes in structure the UI people want to make to CSS, etc.

But maybe this is a topic for another issue/thread, with this issue being more of a broad list of features it should have rather than implementation details? I have some questions/suggestions to pose/make on the admin area, which I'll probably start a new issue or two for.

[iwyg]

BTW, can we move the discussion to something other than e-mail?

Am 14.04.2013 um 13:42 schrieb David Oliver [email protected]:

+1 for a fresh start with the backend interface. I imagine there will potentially be quite a few fairly fundamental changes made in underlying functionality/approach, such as the one @nilshoerrmann outlined, and we don't want to have to worry about fitting in with a previous version's markup structure, CSS and JS. There may also be improvements/changes in structure the UI people want to make to CSS, etc.

But maybe this is a topic for another issue/thread, with this issue being more of a broad list of features it should have rather than implementation details? I have some questions/suggestions to pose/make on the admin area, which I'll probably start a new issue or two for.

—
Reply to this email directly or view it on GitHub.

[DavidOliver]

@iwyg, this discussion is already at Github: #1

[iwyg]

m( vanish

[brendo]

• Unit testing for everything. This saves hours and hours when trying to package new releases
• A build script. This will save time when packaging a new release
• One CSS and One JS file for Symphony. We can have multiple files in development, but the build script will combine them for distribution. This is best practice and if you've ever used Symphony in a shared hosting environment or on a poor connection, you'll agree
• Better scalability support for cloud hosting
• A plug n' play architecture for core components like templating, databases, caching, logging (PSR-3), email etc.
• A Profiler that makes sense and produces information that everyone can understand
• A Debugger that has state and syntax highlights on the client, so the server is not slowed down
• A more seamless integration of publishing for the frontend and backend
• Flexible fields that can be migrated to other types

[designermonkey]

I threw together the beginnings of a project proposal.

[jensscherbl]

PSR-0 compliance

Why no PSR-2 compliance? Or at least follow Laravel's guidelines, which include PSR-1.

[jensscherbl]

• The goals for Symphony 2.4 (structure stored in files, only content in the database) should remain intact.
• Also it would be interesting for smaller, mostly static sites to store the content itself on the file system, like seen in systems like Statamic or Kirby. Maybe a SQLite database would be a good compromise without too much additional complexity?

[nils-werner]

The goals for Symphony 2.4 (structure stored in files, only content in the database) should remain intact.

Apparently, nowadays you don't save the actual DB structure but only its changes (migrations) from one version to another in your files.

The first migration creates the table, all following ones only change or drop it.

[jensscherbl]

The first migration creates the table, all following ones only change or drop it.

Not sure if I get this. Like Database Synchroniser?

[DavidOliver]

Laravel 4: Migrations and Seeding. It lets developers and sysadmins easily update database structure based on version controlled code.

But I haven't got my head round whether or not Symphony's sections could/should use this...

[nils-werner]

The gist of it: For each change to the DB structure you create a "migration", identified by a date (and inherently its place in the ordered list of migrations). The database knows which migration ran last and your migration script can find out if there are any new migrations available. Only those will be applied (in the right order, obviously) when you migrate.

So instead of having a smart algorithm that knows how to manipulate your table to end up with what you want you tell it exactly what to manipulate.

[lewiswharf]

Another benefit of using Laravel 4: Migrations and Seeding is that it allows you to rollback if needed.

[nickdunn]

Yep, just like Database Synchroniser, only cleaner. You don't need to store the actual SQL commands themselves, instead a meta language describing the process e.g. "Add column "title" to Posts".

After having used Rails for a year, if I returned to using Symphony daily I'd miss:

• migrations when using an SQL db (not needed for noSQL)
• the ability to choose noSQL if I want (note: this does NOT mean I can just swap them at any time. When using mongo I still query as mongo queries (inc. map/reduce), and when using SQL I still write some queries using the SQL syntax of that db. This is unavoidable and expected. Do not waste time aiming for 100% db abstraction is it is not achievable)
• ORM! I haven't written an insert/update in 14 months. Leads me to...
• MVC! Symphony is already close, so enforce it. With Rails we have ActiveRecord which is the ORM (this is where model relationships happen), and then something like Mongoid which is the database mapper. Keep the class-based ORM and the db mapper separate
• I'd miss ERB. I don't miss XSLT. We loved XSLT because XPath made cross-referencing nodesets easy (e.g. for combining the output of two DS). But having a controller pass you properly nested model classes in the first place means your views remain light anyway! Loops and variables.
• routing! In code! It's just a config file I can edit
• no restrictive UI! Symphony gets clunky when you want to do complex things, because everything had to have a UI. Writing a model in ruby I have a very clean syntax for defining its fields, how it should validate, how it should persist (if I want to), and how it relates to other models (see ActiveRecord). No UI restricting how I work, meaning validators can have numerous options without needing a UI to support them
• the asset pipeline. Automagically process my SASS, concats and minifies my files and revs file names in production to cachebust
• localisation of site furniture (labels etc) is really easy using yaml files
• config files are split into environments for dead simple management, and deployment with Capistrano is a joy

I'm sure there are more but this is my starter.

Some other ideas:

• SQL is fine. You don't need noSQL. But get ORM and relationships right!
• if you're aiming more at developers, provide command line tools and assume they are comfortable writing object oriented PHP under MVC: don't try to UI the lot. We are developers, we use a text editor all day. Developers in general are getting more savvy (git, command line etc) and this will only improve. I'd consider no UI for sections, pages and data sources.

There are two "backend UIs" for Rails. I forget their names. But they provide a super easy DSL for defining your UI. Just add anew rules to your models (sections) and you get a sortable, filterable table UI. I know Symphony is more than this, but I think they're good inspiration for the power that code-only affords. Lets you focus on Symphony being the UI for content management, not Symphony being the UI to build the UI for content management :-)

[jensscherbl]

Things it should have

• Something like URL Router already baked in.
• Something like Order Entries already baked in.

[iwyg]

So, in a Laravel context, the URL Router would be some GUI or config-tool for /app/routes.php ?

[designermonkey]

I would personally opt for all our config being in XML, and we change the routes.php file in Laravel to use parsing functions to parse that xml into the required php Routes etc.

[iwyg]

like this one?

[designermonkey]

Heheh, yeah. Just didn't want to say it ;)

I just want to re-iterate that I don't want to see this being something where someone could install Laravel and then the Symphony components on top. This is to be Symphony. Configured and structured how we want it to be, but running on Laravel.

I imagine this to not to even resemble Laravel when we're done as that should all be hidden in the /symphony folder.

[brendo]

I've just closed off a bunch of Symphony 2 bugs because their scope exceeds the Symphony 2 project. I've referenced here so we don't forget what mistakes/shortcomings we've done in the past. Some of things are solved instantly by using a framework, others are more conceptual or implementation details:

• Switch to PHP's DOMDocument et al. symphonycms#1676
• Generating HTMLPage Partials symphonycms#1588
• Separate HTTP server logic from apache only. symphonycms#1545
• Alter Symphony's file structure (sandbox /manifest, /workspace inside /app) symphonycms#1477
• Suggestion: use XSL for fields and content pages in the admin symphonycms#1463
• Obliterate about() methods in data sources and events? symphonycms#1356
• Fix / change session handling symphonycms#1355
• Add SymQL-type methods to EntryManager symphonycms#1157
• Improve Logging to include more details symphonycms#852
• Implement PDO in the Database class symphonycms#803
• Abstraction of core fields to extensions  symphonycms#788

[designermonkey]

Also, closing major level feature requests as they are out of scope, and already being discussed for Next:

• symphonycms/symphony-2#1681
• symphonycms/symphony-2#669
• symphonycms/symphony-2#1002

[ijy]

This may be an out-there idea but one of Symphony's strength's for me and real unique qualities is it's ability to work with external data due to the way it produces and manipulates XML. Even outside data streams are treated as a first-class citizen within Symphony. With the rise of JSON, and in fact JavaScript for which JSON is obviously the ideal format to work with, it would be really awesome to have a choice between outputting XML or JSON to the page and the same with consumption of data from an external source.

I'm sure Symphony would then find favour with many a JavaScript developer (and JS is where it's headed) and could more easily act purely as a management layer for an API for web and/or mobile applications. Very similar in nature to Deployd. If you're building a JS based application then usually you just want a thin-client on the back-end to provide the data output in JSON format with most of the heavy lifting then being done in your JS framework of choice such as Backbone.js or Ember.js etc. With that addition Symphony could easily fulfill that growing need and open up to a whole new market without sacrificing any of it's current CMS abilities.

I'd probably even say that it could be a core feature as both XML and JSON are hugely popular data interchange formats but it doesn't lock the user into one particular language or way of working. You could even provide a JSON API and an XML powered, XSLT styled HTML output from the same installation. Or even consumption of one datatype and output of another. It would be another area in which current and future technologies and trends are considered and supported.

I'm not sure on the technical difficulties of implementation at this point but just throwing the idea out there. To me that would make it a very unique, and versatile CMS which would be just as happy acting as a mobile API or a thin-client for JS based applications. It would certainly follow the Symphony philosophy and just update it to include the JS upsurgence. Also, just to point out that I don't mean to suggest it drops XML or XSLT but just add an extra format to the mix as an optional input/ouput. Attract them in with JSON and upsell them to XML/XSLT. :)

[iwyg]

AFAIK Laravel's Eloquent ORM is outputting JSON by default.

[ijy]

I remember hearing that that was the default output introduced in Laravel 4 when dealing with Eloquent models or collections. It goes to back-up the popular demand for data output these days. The key part would be making this an easy setting in Symphony so the user easily can choose whether the data from the datasource would be output as XML or JSON to the page. A bit like the YQL console. Raw JSON would be all that's needed really.

Taking it an extra step, maybe even integrating it into a query string in the URL just like making a typical API call where you request the format so one page can output both data types rather than setting up two pages (one for each).

[brendo]

I think it'd be quite cool to have content negotiation so that a page responds to Accept headers and delivers a relevant page based off them!

[DavidOliver]

Accept headers

+1!

[TheJester12]

Thinking about content/entry revisions today. It might be nice to introduce the idea of entry "status". The two default status' might be "draft" and "published". There are several scenarios where this would come in handy:

• Previewing content before the changes go live (especially after the content is already live!)
• Separate buttons: Save and Publish. An entry could be saved without the changes being published yet.
• Plugins could use and create new statuses for workflow types of situations.

Thoughts?

[ijy]

Could this not be handled with a select box field at present with XSLT filtering on 'save' or 'publish'? This is what I have done and it then allows you to set any status options you like or not have it included in the section at all if it's not needed.

[TheJester12]

No, Symphony cannot handle situations like I listed above, I use the method you are talking about above plenty.

Once content is published in Symphony. It is always published. You cannot have an entry that is simultaneously published, and having edits made to it (and being saved). What I'm suggesting allows content to be in multiple states at the same time.

For an example see the Silverstripe screenshot below. It can save entries without them going live on the website right away. You can save them, preview them on the front end, edit them again, show the changes to other people, all without the changes going live yet.

My clients want versioning in case they mess something up. They want to be able to preview their changes before they go live. They want to have processes in place where some people can edit, another person can approve and publish. And it must be able to handle this same situation after the content has already been published the first time.

Symphony needs plugins that can handle more complex workflow situations, and without the core of this being baked in I fear it will never be possible.

[ijy]

I know that more fine-grained publish control is often what content authors want but personally I can't say I've come across that need all that often. It may be a valuable addition to certain workflows as an extension but I'm not sure it would be common enough to be added to the core. I'm sure others on this thread chip in with their opinion though.

[bernardodiasc]

@TheJester12 , maybe this feature fits better as an extension. In Symphony Next will have ACL, so a good extension can control the workflow of the sections/entries based on permissions levels. And maybe the same extension or an aditional one take care of versioning. I think the main goal of the core is to be simple.

[jonmifsud]

To be honest I've had my manager ask me for that functionality at work;
main reason was that he wanted translators to start chipping in directly
rather then sending back to the authors for publishing. Main issue was to
ensure that already posted articles are not broken.

I don't really see major requests for the sort-of functionality; there is
possibly a way to do it but it wouldn't be very clean; It would depend on
what content would be edited in between. For example I would rather not
have the complete entries but the fields handling versioning. Example I
wouldn't want anyone to change my url-handles, the main content-area I
would agree with; however you would technically want to version just that
rather then the whole entry.

Which implementation wise should be simpler for an extension to do; rather
then the core. As the field would just have to 'keep-track' of the current
version; the draft version and old revisions.

On 7 May 2013 20:31, Ian Young [email protected] wrote:

I know that more fine-grained publish control is often what content
authors want but personally I can't say I've come across that need all that
often. It may be a valuable addition to certain workflows as an extension
but I'm not sure it would be common enough to be added to the core. I'm
sure others on this thread chip in with their opinion though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-17561003
.

[TheJester12]

To be clear, I'm not asking for ALL versioning sorts of functionality to be in core. Rather, that the database and system is set up in such a way to handle many different kinds of content, including versioned content, so that extensions can use this functionality. For example, if we were to stick with something like the sym_entries database table, maybe it could end up looking more like this. (Warning, I'm not a database developer... this is just an example)

id	section_id	date columns...	language	version	status
112	14	...	en	3	draft
112	14	...	en	2	published
112	14	...	en	1	revision

[nickdunn]

Agreed. One of the reasons we have passed on Symphony many times is the lack of publishing workflows for draft, approvals. The same concept was brought up a long time ago when discussion how multilingual could have been added to the core (by adding a version or arbitrary flag to the table) so may be worth digging that discussion out (forum or github issue?) to prevent covering old ground.

[bernardodiasc]

@nickdunn I have no knowledge of old discussions about this. I think so it will be required a new database structure, so maybe worth bring this topic for discussion to find a good solution.

For me, language, version and status appear to have the same fundamental behavior (that is tag a version of the entry field data). But they have different interfaces.

For example: language adds multiple tabs automaticaly when multilanguage is abble (and the db copies are alway saved together);

version auto increment an integer or give the option to set/change the version. (if auto-increment or changed, make a copy. if not save in the tracked copy);

status have predefined values, that have access/permission rules. ( status are saved within versions)

Is that right?

[jensscherbl]

The same concept was brought up a long time ago when discussion how multilingual could have been added to the core (by adding a version or arbitrary flag to the table) so may be worth digging that discussion out (forum or github issue?) to prevent covering old ground.

Here you go...

[bernardodiasc]

Thanks @jensscherbl. The discussions about language and version closes the case. Is there any conclusion about status or core ACL?

[jensscherbl]

There are two extensions covering that.

• Versioning
• Author Roles

I guess the authors of these extensions could provide some insights about past discussions on these topics.

[jonmifsud]

As far as I'm aware the current versioning extension in symphony; uses
files to keep track of entries; saying this as on our multi-server setup
when it was setup we had issues with versions being in-consistent across
the machines. (basically rendering it more or less useless...)

On 18 May 2013 18:01, Jens Scherbl [email protected] wrote:

There are two extensions covering that.

• Versioning http://symphonyextensions.com/extensions/versioning/
• Author Roles http://symphonyextensions.com/extensions/author_roles/

I guess the authors of these extensions could provide some insights about
past discussions on these topics.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-18103483
.

[iwyg]

Please don't use versioning. Really. Don't.

Besides of that, versioning and author roles are completely different things as I've pointed out here. There's a reason why I've never released the current version of versioning and that's because of the ACL extension. Why? because it was a mess. Versioning is quite useless without a granular control over draft/staging/approval operations which the current user model of symphony is not capable of. I wrote the versioning extension with the powerful entry staging system of typo3 in mind. The ACL extension did basically what I needed but as I already mentioned, it was a mess.

First conclusion: Entry versioning is dead simple, hooking into the (locked) usersystem is not. IMO what we really need for __next* is an extendable ACL. Things like version control could easily be handled through extensions (depending on the entry model system).

Second conclusion: if I need a complex draft/staging/approval system, I don't use symphony.
Third and last conclusion: no offence but dont't use Author Roles either. Really, don't.

[ijy]

@iwyg That's all really useful to know, for the current implementation and for future considerations to Next. We don't want to be repeating past mistakes so an extendable ACL sounds like a must in allowing some of the above suggested features.

[brendo]

Check this out, Fuel has implemented a abstract template layer. Available options are Markdown, Mustache, Twig, Smarty and raw PHP. Simple concept!

[iwyg]

Yes, you can do this in most of the frameworks, although they might not come with this out of the box.
I think the biggest problem here is that xstl works completely different compared to other (native) templating layers. Most things these solutions are capable of in leveraging some framework awesomeness, you can't do with xslt. E.g. with Symfony/Twig you'd be able to make sub-requests from within the template, which is super handy when your site hast both, static and dynamic parts, or, as another example, bind a form directly to your data model.

That doesn't necessarily mean xslt cannot live side by side other templating layers (see xsltbridge), But you have to be aware that you cannot simply drop-replace it with another one.

[nickdunn]

I second @iwyg, that XSLT is more than a templating language in the traditional MVC sense. Strictly, templating should be logic-less. The power of XSLT is really in XPath and the ability to cross-reference data. Because Symphony's requires you to chain data sources, you need XPath to pull the data together and pluck values from different parts of the XML.

Symphony's object output would mean separate data sources for each model (a customer, a list of orders, a list of products for orders). XPath is needed to cross-reference by IDs to render these. However if in the XML a "customer" object has a child object "orders" which has child objects "products" then you don't need complex XPath and can use a simpler templating syntax to bind the objects to your rendering.

I think you can only introduce a simpler templating/binding syntax if Symphony does more to provide you with the data in a more structured format, removing the need for the view layer to do this restructuring itself.