Search

A RC2 is available

Just a heads up that tonight, Symphony 2.4 Beta 1 was tagged and is available for early adopters and testers to help evaluate and shape Symphony's future.

You can checkout this build from Github to start your adventure. We are working on a migration guide to Symphony 2.4, backed on the success of the 2.3 Migration Guide. It's all a work in progress, so feel free to update or add issues if something doesn't look quite right.

Our goals for Symphony 2.4 are:

  • Drop support of PHP5.2 for PHP5.3+
  • New backend JS routing system to make extending the backend easier
  • Implementation of Grunt to build our backend assets out
  • Removal of XSL Editors
  • Overhaul of the Datasource Editor
  • Symphony::Database() now uses mysqli as a base class instead of mysql. We also have a PDO branch that may land in the final if testing is sufficient (help wanted!)
  • Abstraction of Cache driver to Providers to allow for different cache drivers (again this is definitely in it's infancy in this beta and happy for suggestions!)

Great news.. to clarify, this will not work on an Apache server running PHP5.3 correct?

It drops PHP 5.2 support as far as I know. That's a typo, I guess.

Pheeew, paniced there :)

Yep, typo corrected :)

So does using using mysqli mean that Symphony 2.4 will not run on MySQL? Just trying to understand what that means for the end user.

Also I have developed a Flat Admin theme with a refreshed look that is modern but in line with the existing admin theme and Symphony branding. How would I go about submitting this for consideration to be integrated into Core:

https://github.com/jsimcoe/Symphony-FlatAdminTheme

Thanks @brendo and all. Looking forward to trying it out.

@jdsimcoe: no, mysqli is a very common extension that gives a different API to access MySQL databases. Do you have any screenshots of your admin theme you could share?

Jonathan, some screenshots woulde be nice indeed.

Here are some screens:

My Github repo has the LESS files used to create the override. If we go this route, we could clean up core and use Grunt with LESS or SASS to create a single minified admin stylesheet used for the bulk of the modules, adding in separate files (for login, debug, etc.) where appropriate.

Jonathan to be honest, i personally don't like it Is a mix of styles out there; dotted borders and solid ones, various fonts are used for textareas, box shadow still present, select box still have gradient on it's background, etc.

I made a Vagrant build that automatically sets up Symphony 2.4beta1. I thought you guys might enjoy it: https://github.com/sirlancelot/symphony-vagrant

Thanks for the screenshots, Jonathan.

Your redesign follows the trend of "going flat" but it raises an important question: what problems is it trying to solve? Don't get me wrong, it's a good design aesthetically, but what's the gain for Symphony besides looking different?

I think there is a lot of room to improve the backend, but looking flat is the least important. We use a pretty small font right now, but if we are going to use a bigger size we have to find a (responsive) solution for large index tables. The buttons and pagination need to be simplified and improved in my eyes. It would be interesting to find new, inline ways to configure sections. How do you think your design will help us in this areas?

I'd be interested to hear something about your overall design goals.

I really dig your theme, Jonathan!

While I do think that the Symphony admin area is in dire need of a redesign, I think these custom themes (of which I've done more than a few myself) only get us 10% there. There are some UX and design issues that go deeper than gradients and type sizes, and while it's a valid point to say "Why don't we just start with this 10% improvement," I think the placation does us little.

My opinion (of little weight) is that we're better off letting folks install our themes as extensions for now, and work on contributing our design language and methodologies to those deeper, systemic conversations that pop up on occasion.

If I had my way, the base Symphony admin theme would be highly minimal and easily customizable/extendable, possibly built on top of Sass extends or the like, but that's a topic for a different, rather boring thread.

Really can't wait to try out 2.4! Grunt + new JS routing sounds brilliant.

The problem is that we currently just hold Symphony's UI on trust: there is no general and long term design concept. And when I say design I'm not talking about colours or trendy styles - that's just execution. I'm talking about problems the UI should solve and those that are out of its scope.

"Themes" are not our problem, interactions are. We are not handling mobile devices, we are not taking care of touch. We have a very flexible system that can scale from small to large projects but the UI makes basic mistakes when it comes to complex or large setups.

It doesn't matter if we use LESS, SASS or vanilla CSS, if we use jQuery, Angular or plain JavaScript as long as we don't know the main design targets for Symphony in the year 2014. We are working around five year old concept that were drawn before a tablet market even existed, before XHTML was dropped and JSON became the defacto standard for web services.

First and foremost, Symphony is in need of a design strategy.


PS: This is an interesting read in this context: The Dribbblisation of Design

I completely agree— those problems are very much what I was referring to. There are deeper UX issues that dwarf the aesthetic ones, and those can only be solved by systemic rethinks. Worrying about the aesthetic layer is just lipstick on a pig, and it detracts from less glamorous but more important discussions. With that said, I've tried reworks of the admin area that solve these problems and it's pretty excruciating; admin.js is less than friendly, CSS selectors are overly complex (.frame styling, anyone?), etc..

One of the first things I asked Brendan re: 2.4 was about increased backend extensibility, especially as it relates to deep admin redesign efforts. I understand this release won't get us leaps closer, but I'll keep plugging away nonetheless.

That's a hot list.

Symphony::Database() now uses mysqli as a base class instead of mysql. We also have a PDO branch that may land in the final if testing is sufficient (help wanted!)

PDO would be sweet. What needs doin'?

I think there is a PDO branch already on either the main repo, or Brendan's fork.

PDO should be considered a minimum standard. If you're still using mysql(i)_real_escape_string for user input sanitizing, your application is likely to be vulnerable to sql injections.

What is Symphony holding off of using an already existing DBAL?

What is Symphony holding off of using an already existing DBAL?

The usual, resources and the fact all extensions would break :)

hm, true. What about compat. layer around an existing DBAL, e.g. a Symphony DBAL Decorator or Facade? Guess the major issue would be to allow for raw queries, right? I think bean would be capable of this.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details