Symphony.

There is some basic functionality, provided through many of the extensions, which aren't available except through the command line and not the admin interface. There are also some software developer abstractions in the core that don't see the light of day in the GUI. Where you might call relationships, ORM, and writing PHP as 'software developer tools'. These are exactly GUI-worthy (transparent) that will make this a CMS. What would it take to get these things into the GUI?

... having a clear 'opinion' (as clear as what a field is) in the writings about Symphony's design architecture. I would probably go to the extent of even writing a preliminary draft of the documentation first. You could also look at it as ubiquitous language.

EDITED Symphony's design architecture.

@Glen: can you be a bit more specific? I really don't understand what you mean with

There is some basic functionality, provided through many of the extensions, which aren't available except through the command line and not the admin interface

Or

Where you might call relationships, ORM, and writing PHP as 'software developer tools'. These are exactly GUI-worthy (transparent) that will make this a CMS. What would it take to get these things into the GUI?

What are you referring to?

Basic Functionality Extensions aren't. Many functions that a Administration Interface (AI) user would need to include for their functional website (i.e. members and email templates) are necessary and therefore not extensions, but core to the AI user. However, from the AI you can't select and install extensions, you must use the command line. See this.

Software Developer versus Admin Interface User Presently relationship management, ORM, and PHP are discussed from the software developer level (these are only examples). Therefore, they'll probably be implemented at that level. AI users needs these things as badly as the developer, and if it's something you do at the end of development it won't be simple enough. If you begin with the question:

How can I implement this in the AI?

The answer to this question will make it a core 'opinion' (something that everyone, AI or software developer move towards). It also boils the design architecture down and keeps it Simple.

One point I would like to emphasize is that you, as software developers, should try to create design architectures that the AI user can use because it also lends itself to keeping other software developers up-to-speed on the latest new thing. Using the idea that you're creating a CMS will set up these boundaries.

@glen, I'm reading your thoughts but not really understand. The extension don't need any command line to make it work, use a Git command line is an alternative (better one). Also Symphony UI and workflow is pretty good, and much better than others CMS with same approach. I've made many websites without touching any PHP or command line at all, said that, I think the community is going in the right evolution path.

Maybe I missed your point... Maybe you are not following UI team discussions...

Is there a way to use the Git command line from the Administration interface? I might be surprised, but I don't think so. The back-end interface is Administration Interface (AI) of the following statement from wiki:

... centralize data editing, publishing and modification on a single back-end interface.

I've tried to make points from the software developer's viewpoint: it'll provide better communication to have all CMS functions available in the AI, it'll better focus the development.

I've tried to make points that many important functions are not available via anything except the command line/git command line/anything except the AI.

I mentioned the idea of PHP as a template layer like HTML or XSLT.

I know Symphony is one of the best CMS, but it's not simple enough or deployable enough for someone who is not well-versed with the command line.

There's no command line in the backend. But you still can install extensions without command line.

Did you mean like Wordpress, a search and install plugins inteface?

@glen: I still don't get the command-line stuff. You do not need to work with git to install Symphony or an extension. This can be done by downloading a zip file and copying it to a file system directory, which is the same for many other CMS systems. The extension can then be enabled from the administration interface.

@remie Good point about being the same as many other CMS systems. I am trying to convince you to do one better like Joomla 3.0 or Wordpress Plugins where you don't have to place it in the server directory. You can just upload it by way of the AI or anything to avoid server directories. @germchaos I really do mean the file-system prompt is the command line. It's a semi-strict definition that I'm pushing. Except for initial installation, every other CMS part is accessible from the AI.

There are also some software developer abstractions in the core that don't see the light of day in the GUI.

Relationships are an example of one thing should be exposed to the Admin Interface user. The problem resides in the intricacies of one-to-one or one-to-many mechanisms work or where indexes are applied. Too Complicated. How could we expose relationships to the AI is a simple enough form? This type of question is what I'm trying to incorporate into the conversation.

Relationship Example

An attempt using Ubiquitous Language described in Eric Evan's book Domain Driven Design.

Create new Sections types with the following definitions stolen directly from the book.

1. Entity

   not fundamentally defined by their attributes, but rather by a thread of continuity and identity.

2. Value Object

   Many objects have no conceptual identity. These objects describe some characteristic of a thing.

Entity sections describe things that have identities such as a person identified by their name or their social security number. I would say that the key needs to be unique. The ORM can be done with a table per section. This will speed searches. It would also be closely linked to the field 'foreign key'. 'Foreign key' will be set in other sections. Within a data source a 'Foreign key' can dynamically expose any of the fields in the Entity section.

Value section must have an Entity section that it relates to. There can be one-to-one or one-to-many Value sections. It is also stored with a table per section.

When a child is drawing, he cares about the color of the marker he chooses, and he may care about the sharpness of the tip. But if there are two markers of the same color and shape, he probably won’t care which one he uses.

.3. Domain list specifically used for drop-down (combo box) lists.

These three sections would work well for things like album (entity) - songs (value) or order (entity) - order detail (value) - category (domain)

I do not tested this extension yet, but maybe you can have a look Extension Installer (Install extensions directly from the Symphony Admin interface.)

Just need to make it 2.3 compatible.

I think you're confusing developer tools with publisher tools.

Creating a site, installing extensions and making it all work is developer work. These tools need you to know XSLT, some PHP, CSS and maybe some Git (on the command line if you will). However these are not the CMS parts of Symphony.

To use the publisher tools you only need a modern webbrowser and a login. This matches exactly with what you cited earlier:

... centralize data editing, publishing and modification on a single back-end interface.

Developer work is not "data editing, publishing and modification".

Part of the Symphony ethos is that we assume nothing about the bespoke CMS that a developer will build for a designer and author. It is purposefully limited in what the core can do.

There is scope in the new platform though, to add some key features that are already provided by Laravel, but these will still be limited to keep in line with the ethos of non-assumption.

Having that separation between developer and designer/author means a dev will put the package together by installing the required extensions. If this causes a crossover of skills for a designer, then that should be seen as a good thing. To progress in this industry, you should learn how to do these things.

When it comes to relationships etc, I wouldn't worry about going into detail there. Laravel has a great ORM. Also, in the final release for 2.x in Symphony, I did a load of work on visualising associated content with Nils H and Brendan, which is in the integration branch.

Just tested this new feature on integration branch... Very nice indeed!

@germchaos I will definitely check out the Extension Installer.

Creating a site, installing extensions and making it all work is developer work.

@phoque I've been trying to differentiate developing the software and the developer who publishes websites. I would like to separate the two as the software developer uses the command line and the website publisher uses a CMS. I know this is different than what you're saying, but because of the improved communication among software developers I think it would even be to your advantage and I've outlined several other advantages above.

@designermonkey I like the Symphony philosophy, but maybe some parts of certain extensions can be moved to the core because their importance to the Core Symphony Definitions. As example, there's a move to make the front-end and back-end of the CMS created with some sort of an interface factory (my wording). This is good thing. Maybe a log-in engine should be part of this interface factory. The log-in engine should be exposed to the Admin Interface (AI). This is part of the Members extension.

Related to the ORM, I just said to expose the great part of it to the AI.

Part of the Symphony ethos is that we assume nothing about the bespoke CMS that a developer will build for a designer and author. It is purposefully limited in what the core can do.

Definitions and documentation for extensions don't live up to high standard the core provides.

Having that separation between developer and designer/author means a dev will put the package together by installing the required extensions. If this causes a crossover of skills for a designer, then that should be seen as a good thing. To progress in this industry, you should learn how to do these things.

File-system access varies so widely from system to system that it becomes a wildcard for anyone expecting someone to learn it.

@glen I think someone had a stab at the kind of thing you're alluding to for single click installs. I've not worked with it but I know the person who developed it. It's not really compatible with a 'git' style setup but if you want to install extensions from the server then that's kind of mutually exclusive with source control!

Symphony Extension Installer

@davjand Thank you for the extension. This is part of what I've wanting in Symphony-Next. I'd like to summarize the above conversation since it was rather length.

Summary of the Admin Interface Conversation I think what I've been asking for is counter to the Symphony culture which includes:

1. Never assume what parts the website creator will need to use. In other words, keep the core as small as possible and allow the website creator to add the extensions necessary.
2. Symphony is a tool that requires a large set of skills including understanding of the file system, permissions, .htaccess, and all the parts that make the website work. These are all necessary to get along in the website industry.

I see software as a means of communication through a carefully constructed user interface. It can lead a user to understandings background structures and concepts that normally go far above their abilities to learn under normal circumstances. Initially Symphony did this for me through its user interface and guides, tutorials, and articles. I ran into a much larger learning curve when I started adding in extensions. Some, like the Members extensions, were incredibly easy to learn. Others didn't match this level, but were just as important to my website. There has been pretty strong resistance to even the conversation to bring parts of extensions into the core by asking one question: Could a Admin Interface user implement this? I've strongly argued that it would be critical for something like the Symphony Extension Installer be incorporated into the core. I've also tried to argue that the command line/file system is a crutch to avoid answering the one question.

The conclusion that I've drawn is that you need to have an advance set of skills and already understand how websites are put together in order to use Symphony.

I've strongly argued that it would be critical for something like the Symphony Extension Installer be incorporated into the core. I've also tried to argue that the command line/file system is a crutch to avoid answering the one question.

Symphony's core concept is to keep it as lean as possible, so a feature like this that only assists some users is definitely for an extension, especially as it's infrequent use case (once your site is live, it's even more infrequent).

We are not aiming to be the next Wordpress and I strongly doubt we will ever cater to that sort of market (no tech knowledge required users).

The conclusion that I've drawn is that you need to have an advance set of skills and already understand how websites are put together in order to use Symphony.

It's true, we do set the bar a little higher for our users. We anticipate most of our users are designers, developers or agencies that are seeking something that lets them get in and build a great website for their client. I agree that the bar is a little too high at the moment, our documentation definitely needs some love, but to be honest it's unlikely to change to ever be as simple as Wordpress.

I personally think this is best use of our resources and one of the reasons Symphony user's are quite passionate of keeping a bar in existence. I am more interested in building things that let developers do amazing things with Symphony, not creating a product so anyone can start up a website.

Symphony is a tool that requires a large set of skills including understanding of the file system, permissions, .htaccess, and all the parts that make the website work.

This is not entirely true! A few years ago I wore Windows and make websites with Symphony without concern about advanced stuff. Approached development using zip downloads both for the Symphony and Exetensions and sending to server with FTP. The only new thing I needed to learn is XSLT that is great/simple as HTML or XML. Of course PHP and MySQL are prerequisites, but in many Symphony websites I build I do not even touched this things...

I mean, Symphony is much more about Logic than IT skills. It's possible for non-programmers use it, but they need to be smart too.

Symphony's core concept is to keep it as lean as possible, so a feature like this that only assists some users is definitely for an extension, especially as it's infrequent use case (once your site is live, it's even more infrequent).

This mean that is better focus on powerful extension plugin capabilities than make Symphony a bizarre Airplane Panel (as many others CMS).

@bendo Well said and fantastic to hear!