search

symphonycms / symphony-next

The next big thing.
19 stars 1 forks source link

Things it should have #1

Open nils-werner opened 11 years ago

nils-werner commented 11 years ago

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

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

nilshoerrmann commented 11 years ago

@michael-e: Remember a few talks we had on the phone? We are both Symphony "developers" but this means completely different things to us. So yes, I'm not talking about the authors but the ones setting up Symphony. If I think of us, Johanna and I, we are using the system as designers and we need a GUI and no plain PHP files. We use Symphony because it lets us build sites without hiring a programmer.

twiro commented 11 years ago

Regarding the GUI for Datasources & Co I'm completely with Nils - Beeing mainly a Designer I chose Symphony for exactly the same reasons (not having to hire a developer for building complex sites). Having worked with Symphony for years made me a kind of "developer" myself, but I still would feel very uncomfortable with loosing the GUI for setting up my sites.

If you not only want to attract developers with Next, but also designers (and the current backend attracts a lot of them) you have to give them a great GUI to play around with.

designermonkey commented 11 years ago

I would rather that everything we have to configure is in an xml file, so datasources, events, sections, pages. That way we can allow more design oriented people to edit these files easily (it's better than php), that being said, Symphony seems to primarily be a UI that sells the software to people, so we can't avoid that without losing lots of members. We are a CMS first, and a CMS is a UI.

Granted, it should be built after we get the API working first.

jensscherbl commented 11 years ago

I would rather that everything we have to configure is in an xml file, so datasources, events, sections, pages.

Right. Features planned and agreed on for 2.4 shouldn't be forgotten in Next. I don't see how the mentioned Laravel "migration" stuff has the same benefits (easier deployment, reusing site structure in different projects, better ensembles, etc.).

iwyg commented 11 years ago

I would rather that everything we have to configure is in an xml file

I've actually already done this :)

DavidOliver commented 11 years ago

In case it makes any difference to what you're discussing, it looks like Symfony enables XML configuration of more things.

iwyg commented 11 years ago

yes, indeed.

jonmifsud commented 11 years ago

Plenty of stuff mentioned here; on the GUI whilst being primarily a developer ( I do plenty of php ) I still find it pretty useful, and whenever we get new guys running its definetly easier to start with rather then writing code. I would agree with Nils that its not entirely flexible at the moment (we all know this).

Having a solid API will make it easier both for us to develop complex datasources and to build a decent UI which will allow at least the most common day-to-day structures to be built.

designermonkey commented 11 years ago

I think we should have some kind of support for multi-lingual content from the core, even if it's just 'something' that can be extended, but 'something' needs to exist at a core level.

DavidOliver commented 11 years ago

I think we should have some kind of support for multi-lingual content from the core, even if it's just 'something' that can be extended, but 'something' needs to exist at a core level.

Perhaps something quite generic/flexible that can be used for multilingual amongst other things? A 'multiple-values-allowed-from-a-predefined-list' option (such as a list of languages, or versions, or anything) for each field?

designermonkey commented 11 years ago

That makes more sense, yes.

jonmifsud commented 11 years ago

Flexibility for multilingual would be neat; it would depend how its implemented there are various things which change when going into a multilingual environment.

For example I've even been asked to do a checkbox in multilingual mode?! So articles could be published separately in each language. Language / field option as suggested would be pretty neat I think.

What's important in multilanguage is the Symphony Page handles not just the entries; useless to do one and not the other... currently the solution using PageHandles is not very neat... still leaves the original url working.

nilshoerrmann commented 11 years ago

I'm not a big fan of these "50 things you should know" posts, but I stumbled across this that might be interesting: The Web API Checklist — 43 Things To Think About When Designing, Testing, and Releasing your API

jonmifsud commented 11 years ago

Interesting about the 410 error code; would be interesting to see how this could be implemented. It would make sense in many applications I presume instead of the standard 404. Mentioning that it would also be nice (though could be by extension) that one could have the option of adding redirects (301s) when renaming a page handle (or even possibly on entries)

I tend to find myself doing 301s manually in htaccess following a client request to change the url of a page.

TheJester12 commented 11 years ago

I'll throw my opinion out about a few things:

  1. I'm more of a designer like nilshoerrmann, I love that the UI of Symphony can get me 99% of the way to a really complex site really fast. Please don't get rid of datasources and events UI's.
  2. I agree with michael-e that 2 different kinds of users (Users and Members) is confusing. A more advanced ACL would be nice within Symphony to limit what users can view/edit/delete.
  3. I think Symphony is best as a CONTENT Management System. Content includes complex things like multilingual content and versioning of content. So I'd love to see these thought about within the core.
brendo commented 11 years ago

I've tied together a pretty high level About page that loosely sums up this thread.

s-e commented 11 years ago

My mum's blog is proud to be featured in this post!

nilshoerrmann commented 11 years ago

Nice writeup, Brendan.

I have small wish though: Can we please no longer use the term "core extensions". All extensions are extensions of the core and there is no triad of the core, the core extensions and other extensions. We just have the core and extensions where some are provided by the core developers and others by the community. I always found this term misleading because it implies a special importance of the so called "core extensions": if a function really is essential to the core, it should be right in there and not be provided as extension.

Saying this, I also think that official releases should provide nothing but the core – no extensions, no default workspace. Instead we should think about creating special example packages that can be used as a blueprint for your mum's blog or your small agency website (I'm not calling this ensembles because I'm not convinced that this concept worked out that well).

iwyg commented 11 years ago

I'm not convinced that this concept worked out that well

Me neither.

I think it's a good idea to offer different bundles, especially for new adopters. Would make getting started much easier.

bernardodiasc commented 11 years ago

I like the packages concept... Not sure that even is a good idea, but its cool. Like this https://podio.com/market

designermonkey commented 11 years ago

We use Podio at work for our project life cycle. I like the app market, although in my mind that would be more a website feature.

iwyg commented 11 years ago

hm, maybe more something like http://www.joomlabamboo.com/

ijy commented 11 years ago

You need caution with the 'bundle' concept. If Symphony ever turns into a WordPress theme market where you buy a Symphony site for $10 I'm outta here!

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

That sums it up well for me. Unit testing and build tools are super useful and becoming a standard for modern web dev.

One CSS and One JS file for Symphony. We can have multiple files in development, but the build script will combine them for distribution.

Similar to the asset pipeline in Rails. I've been using grunt.js as my build tool for quite a while. It's highly flexible and in the same principle as Symphony and Laravel it provides more of a platform to build your uniquely tailored scripts rather than be opinionated in how you need to go about things. Compression, concatenation, image compression, integration with Sass, Compass, Less, Linting, Unit testing. You name it you can do it all from a simple JSON based config file.

Better scalability support for cloud hosting

Again a future direction of web hosting and something needing to be catered for. I run cloud hosting exclusively now and and it would be great to take advantage of memcache(d) on the server for super performance.

A more seamless integration of publishing for the frontend and backend

Is this related to taking more of a viewpoint of less of a divide between the back-end (admin UI) and the site front-end?

Flexible fields that can be migrated to other types

Without data loss! Nice.

ijy commented 11 years ago

I totally agree with comments regarding the Symphony UI thought. That is Symphony to a lot of people (including me) and it needs to remain the focus. The vast majority of sites should be able to be built from the Symphony UI alone without needing to touch (server-side) code. A more modern and versatile core should be to provide an easy way to extend the UI and not be in place of a UI. That way it caters for those who like to work either way or even both.

jonmifsud commented 11 years ago

If Symphony ever turns into a WordPress theme market where you buy a Symphony site for $10 I'm outta here!

I think we're referring to ensambles showing the most common use-cases; rather then the outdated example(s) we have at the moment. This could be 2 or 3 which highlight/show best practices. It should not be a 'theme' you're expected to just use on production but something to learn from.

I've been using grunt.js as my build tool for quite a while.

We just started using this for Javascript; it seems a very interesting concept; hopefully we'll add in sass/compass to it rather then use a different compiler. It makes everything easier to work with with far better dissected source files. I don't see this as a must for developers to use; however I think could come handy when re-building the core.

Flexible fields that can be migrated to other types

That would be nice; Sometimes you want to do something slightly different or extra.. instead of hacking the field it would be easier to create a new one; and just migrate the data.

ijy commented 11 years ago

I think we're referring to ensambles showing the most common use-cases; rather then the outdated example(s) we have at the moment. This could be 2 or 3 which highlight/show best practices. It should not be a 'theme' you're expected to just use on production but something to learn from.

I understand. Depending on the implementation (and makerting) however it may be open to abuse. Just something to keep in mind. A similar thing concept actually exists in ExpressionEngine where 'themes' are possible but in all honesty I don't know a single developer who's ever used one or even thinks of it. All attempts at a theme marketplace for EE have also failed (thankfully). They present this as an option on installation so I'd probably keep this out of the core and available as a separate download. Ideally you don't want to delete before you even get going.

Regarding grunt.js it really is super versatile and useful. It can handle your CSS/Sass, perform lossless compression on JPGs and optimise PNGs, keep a watch on your files in combination with LiveReload and pretty much anything else you can think of that you'd like to include in a build process. Nice integration with require.js too.

iwyg commented 11 years ago

Forget extension delegates; instead have events sendable and receivable from anywhere in code

Laravel has a handy PubSub engine, though I don't like to see event triggers in my code. This should be handled as an aspect. Unfortunately we don't have AOP in Laravel.

ijy commented 11 years ago

I don't really have anything against the observer pattern. Generally loose coupling is a good thing. I think Laravel uses a combination of PubSub and route groups to cut down on repetition and keep inline with the single responsibility principle. I'm not familiar with AOP but it looks like the Go PHP library can be integrated if needed and seems fairly popular.

jensscherbl commented 11 years ago

Things it should have

iwyg commented 11 years ago

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

designermonkey commented 11 years ago

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 commented 11 years ago

like this one?

designermonkey commented 11 years ago

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 commented 11 years ago

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:

designermonkey commented 11 years ago

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

ijy commented 11 years ago

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 commented 11 years ago

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

ijy commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Accept headers

+1!

TheJester12 commented 11 years ago

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:

Thoughts?

ijy commented 11 years ago

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 commented 11 years ago

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.

screen shot 2013-05-07 at 12 34 55 pm

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 notifications@github.com 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/symphonycms/symphony-next/issues/1#issuecomment-17561003 .

TheJester12 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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...