Search

@kanduvisla opened an issue about the possibility of rendering the Symphony admin pages with XSLT.

Symphony 3 had been developed to make this possible.

I have created my own experiments with this in mind. I'd like to continue those experiments, starting with a collection of all the Symphony admin page layouts, rendered as plain old HTML.

View the Symphony Demo in the Markup Library. Now, if anyone wants to find out more about Symphony without going through the trouble of installing (which is really no trouble at all), just look around the Symphony admin area and the debug pages to get familiarized with how the system works. Feel free to fork the html-symphony repository on GitHub.

No harm can be done, because this is just plain old HTML.

Debug Pages

One note about the ?debug pages: I have only rendered the pages for the Home page, as I was just doing a copy/paste from a local install, and I didn't want to do the whole set for every page. I figured people could get the basic idea based on only the Home page Debug and Profile pages.

Building the Admin with XSLT

So, the next step is to rebuild the admin with XSLT. I already have some ideas about using Nick Dunn's Section Schemas extension and Form Controls templates to dynamically build the Publish pages. But I would also like to dig a little deeper into how Symphony 3 proposed to do this.

Portability of templates between scripting languages

My ultimate goal with this project is to explore the possibility of the portability of XSLT templates between multiple scripting languages as a way of establishing XSLT as a standard for templating in the process of front end web design and development.

Nice! I am a big fan of this. In fact, I think going from php to xslt is easier than we think. We already have the functions that generate xml from a php array - if we were to create admin datasources (or models in the MVC terms) and some simple xslt templates I think we are already 80% there.

Most of the UI in the backend is very repetitive (think of the table and form view, they are basically the only two views we have, and the elements in these views are very similar), so building the templates themselves shouldn't be too hard either.

Since I have built a rather big administration interface in the frontend (using XSLT, datasources and events), here is my 2 cents:

The hard part is creating forms from XML data. But validation is still harder.

I am rather sure that we would introduce some compatibility-breaking changes to event XML. (We would use the same event and datasource XML as in the frontend, right?)

(We would use the same event and datasource XML as in the frontend, right?)

I'd say this is not really necessary. I think that while the templates can be easily reused, this does not really hold for the data in the backend. In most pages this means you'd have to create a datasource that will not be reused anywhere (configuration, users (index and detail), section structure (index and detail), section content (index and detail)...

Also, the most important part of datasources at this moment is the GUI for building them - do you suggest having the same for the core, or are they managed and setup by code only?

Hm, interesting point. Actually rendering portions of the adminpages with xslt is what I'm currently doing for Soario. It's not ideal but It removes a whole lot of nasty code. I'm not a big fan of the whole Adminpage concept, though. I'd rather have a clear separation of business logic and views, speaking Controllers and Views.

Controllers + views get a +1 from me!

Could I ask what the purpose of this is? Would it mean we could bespoke design the admin side using xslt?

Yes. Actually you already can do it, at least for parts of the admin pages, e.g. Page::Form, Page::Context

@michael said

(We would use the same event and datasource XML as in the frontend, right?)

+1 for this. There should be a unified event system for both frontend and backend. This way, one can reuse the code easily.

I am rather sure that we would introduce some compatibility-breaking changes to event XML.

I'm sure as well. Taking note to the new Relations system that is on the way, perhaps it's time to merge EventEx functionality into the core? (the creation of relations between entries in XSLT).

Something like:

  1. create all entries (in Events)
  2. register their IDs (in Symphony, analyzing Event result)
  3. build relations (in Symphony)

Could I ask what the purpose of this is? Would it mean we could bespoke design the admin side using xslt?

Good question. I agree that it seems a good idea to do so but I'm curious as to what the main purpose is for doing so? I would imagine to make the back-end easier to design & manipulate when adding new extensions & functionality? A more consistent approach to development of the front-end and back?

@munki: Could I ask what the purpose of this is? Would it mean we could bespoke design the admin side using xslt?

@ijy: I would imagine to make the back-end easier to design & manipulate when adding new extensions & functionality? A more consistent approach to development of the front-end and back?

In short, "Yes."

For me, the experiment started with the first open source releases of Symphony 2, when I was working with the Section Link field. There were limitations at the time (and still are) with the existing fields to create relationships between sections. So, I extended the admin area with XSLT to create custom user interfaces in front end pages with admin only access. It also allowed the ability to use the "Allow Multiple" event filter for saving multiple entries with a single event trigger.

In comparison, the process to create content pages and forms with PHP for extensions seemed very clunky to me, so I've always wondered if it would be possible to keep the process of creating views consistent for both the front end and the admin.

While I'm not going to be that "dick developer" with a negative response about all this, I think we need to tread carefully here for two reasons:

  1. Symphony CMS is a content management framework, and having a very robust admin area is a key selling point for a lot of reasons, and to a lot of people. We have to be very careful to not accidentally take 15 steps backwards on this, as it will have serious detrimental effects on our standing in the wider community as a brilliant solution.
  2. On the issue tracker we have completely de-scoped this for the time being as we have some very big problems/features to find solutions for, and they are features that will make this all happen, but they must happen first.

If there's one thing we need as a community, and core dev team, it is focus. I/Brendan need to sort out the milestones on github to create a roadmap for our development so we can get to features like this, as I too agree that it is the best way forward, but we have so much to do already.

Please keep experimenting, even coming up with XSL template skeletons, but please please please don't expect this to happen any time soon (within the next 6-12 months), you will just get despondent about it.

@bauhouse It makes sense and what better advertisement for a system providing XSLT as the template language than to actually use it to build its own interface. In theory it would provide a more consistent approach on both ends.

@designermonkey Wise indeed. It sounds like you guys have it well under control and a lot of work on your hands for the coming year. If things are on a map then it levels expectations and means things can happen in the right order without anyone getting despondent.

Is this planned for Symphony 2 or is it more of a Symphony 3 feature considering it requires a bit of an overhaul of the back-end and related features?

@designermonkey, I am not expecting this any time soon. And I realize there are other priorities on the road map at this time. So, thank you for clarifying the goals of the core dev team.

I am only continuing my experimentation with rendering the admin with XSLT. I'm curious to see how far I can get and I'm interested in thinking through the XML data schemas that might be needed to build each of the admin layouts. It would also make for an interesting community project.

However, I do not want to dilute the efforts of the core dev team. So, consider this an interesting little side project, with long-term aspirations for inclusion in the core. I would expect this to be a major breaking change, so a Symphony 3 release would seem to be the right fit for a feature like this.

I am not expecting this any time soon.

I understand, just needed to say it as I see momentum picking up here again, after momentum has waned on the main features for 2.4

Not criticising anyone, it is an awesome idea, and thanks for making headway on it. Jut trying to do 'my job' (if I have one, I think) of keeping focus.

Plus, you know I love most of the things you come up with anyway ;)

so a Symphony 3 release would seem to be the right fit for a feature like this.

Which is about where I see it in the current timeline too.

I met a Ruby on Rails developer who was interested in developing a CMS for Rails because he has not been satisfied with any of the available options. We were discussing the possibility of porting the UI and XSLT-based workflow established by Symphony to other platforms. My thought is that if the idea is spread to different scripting languages and development ecosystems, then there is a compelling reason for using XSLT as a common templating language across these development silos.

Long ago, I created HTML-only versions of the Symphony admin UI. I finally got around to stripping away the proprietary data attached to an old repository that was testing out the old beta release of Symphony 3, as it was called in June 2010.

For anyone who might be interested in looking back into history, feel free to have a look around the admin UI of Symphony:

These HTML-only repositories are available here on GitHub:

The starting point would be to overhaul the admin area in Symphony to use XSLT to build the admin interface, as michael-e suggested recently.

I remember seeing some of the early concepts suggested for the old Symphony 3 and thought then they looked fantastic. Seeing and interacting with them in the browser makes them look even better. Sublime!

I can't remember now why those features were dropped as they'd certainly make fantastic editions. The layout selector and fieldset grouping would certainly be very welcome additions and the improvements to the section editor certainly help to keep things nicely contained. Is this something that could potentially be added to Symphony in it's current release stream? Was the reason for dropping them down to being feasibly unworkable in the codebase or just the change of direction and lack of resources for Symphony 3 as it was proposed back then?

Thanks for sharing Stephen. It's great to see them brought to life. :)

Symphony 3 beta

Wow, never realised we're actually that close regarding the UI.

I like the ideas from the section editor, but everything else looks a lot more polished in current Symphony, especially the data source editor.

Just a thought, would it make sense to rename old Symphony 3 beta references on GitHub and new discussions to avoid confusion with the upcoming 3.0.0 release for people who are not familiar with Symphony's history?

The starting point would be to overhaul the admin area in Symphony to use XSLT to build the admin interface, as michael-e suggested recently.

That's not something Brendan and other core contributors should be concerned with at the moment imo. Don't get me wrong, I just don't think that it would solve any issues for Symphony itself and other areas still need more attention.

Doesn't mean people can't work on it as a side project and eventually merge it someday if it works well enough and is kept up to date with the main repo.

Ditto the sentiment about liking the ideas in the sections editor.

I would add that I like the ideas in Extensions. Tabs in the Settings helps organize it a bit.

I also like the User Roles as well (though that is feature/functionality first and UI second.)

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