Symphony.

"That's frustrating. You can't do entry/@id? If so, that sounds like a Reflection field bug."

Aarrggh! :-8

Yaayyyy! :-D

I'd tried several different things: entry/id, entry/id/@id, entry/entry_id, etc. Just never that one. One more extension that I can now shed (pays to know some syntax). Thanks!

Unless I'm mistaken, SSM really doesn't access the entry id. It should use {$id}, and I've tried a lot of other combinations to no avail.

"Unless I'm mistaken, SSM really doesn't access the entry id. It should use {$id}, and I've tried a lot of other combinations to no avail."

I'm mistaken. That may have been how it used to be, but playing around some more I discovered I can access the entry id with {$entry-id}. :-b

Need this great WYSIWYG-editor in symphony !

http://redactorjs.com/

I've been working on this Quma, not sure how far off I am. Getting the editor tied in was a snap, but image/file support may take a little fiddling.

@adam sounds great ! It would be a great feature if the insert link button supports Symphony Pages and Section entry's.

Hi Quma, that editor is quite wonderfull. It would be very interesting to have it in symphony. It would be good to cooperate with other extensions like filemanager for images and so on...

Dear developers, as "frequent user" of the Symphony i'd wish to have the following extensions:

Blueprints Styles & Scripts

Seems strangely that we can create/edit pages, sections, data sources, but no css/js manipulations (except of redundant FileBrowser/Filemanager). Is anyone able to create site without css or js? so why should we use scp/ftp to solve such a trivial tasks?

Hybrid Members

It seems rather obvious that our Symphony sites can't compete with monsters like Google, FB, etc in field of authentication. So why should we store the Members credentials inside Symphony? What if we could authenticate via external systems, but authorize by the Members? (moving towards so called Social login)

Adaptive backend UI

Less important, but still valuable option (at least for me). As seen on the screenshot ( http://cl.ly/image/3V1b3u1Q0a0J ), the editor field is to narrow, whilst the width of existing utilities list is completely unjustified. What if we could have kind of slider/divider between these two areas? Flexible one. Maybe via the "special" button, hiding the listing, thus giving the editor field full width.

Extensions list

What if the authors could provide links to githubs/discussion pages/special personal pages, so that we, users, could easily access the extensions sources via our symphony instances, and not by browsing the Bookmarks, etc.

Thanks in advance, Tim

@timteka There is an extension which allows CSS and JS to be edited. Do you not know Symphony Deluxe? (The name could have been better.) This extension provides an editor with syntax highlighting for XSLT, CSS and JS.

@Petertron I do read about the Symphony Deluxe, but it also seems too redundant. I'm looking for some "natural" way. Why can't we just edit css/js files as we normally operate with *.xsl? :-)

Why can't we just edit css/js files as we normally operate with *.xsl?

Considering Symphony's philosophy to have a minimal core offering only the most essential features and leaving special needs to extensions, the actual question is: why can we edit XSL in the backend at all?

Core developers are in agreement that it makes most sense to work with the files on the server directly using your editor of choice (for all files, including XSL templates). The reason behind this is simple: each developer has different preferences and needs when it comes to editing and it become a really complex task to satisfy these – just think about the dark or light theme problematic. And remember that Symphony is not an code editor, it's about managing content.

The core offers XSLT editing just for historic reasons. Conceptually, I makes most sense to leave this to a dedicated editing extension – Symphony Deluxe is exactly that.

@timteka I'd agree with @Nils, it doesn't quite make sense to edit these things via the backend.

I don't even think of editing any XSL (or any code) for that matter via the editor on the server. As it would mean my local/testing environment is likely to be different then production, which would mean inconsistency whilst working.

I know, this is not what Tim was after, but I raised an issue on Github to remove the XSLT editor: https://github.com/symphonycms/symphony-2/issues/1800

I think we will remove the xsl editor shortly. The vast majority of the users we have never use it.

Inmates, it doesn't make any difference for us (ordinary users) whether it's a core feature or extension :-) Though I still doesn't understand why it's not popular at all among you. Isn't it convenient to be able to finetune here and there the Symphonies sitting behind any abstract PC, not that with home/office environment? I don't try to claim that both ways should be equally convenient, but still.. "Cloud Symphony" seems better for me than nothing when you are away from the office or the partner moved the site to another hosting and didn't give you the credentials yet. Or am i wrong?

It's a useful feature. But it's not a feature the core should to provide out of the box. The editing experience in the backend has always been rudimentary and it wouldn't get any better if we allowed other file types.

Symphony has a really small group of core developers so we need to keep things focussed. Adding flavours and spices using extensions is the right way to enhance the interface: Symphony Deluxe works far better than the core editor, it allows editing, uploading, creating and deleting of files, it also comes with syntax highlighting and folder overviews. It's the way to go.

I've always worked in an agency environment where changes to files are done in a local dev environment through the developer's favoured IDE, then pushed to the production server using source control (Git).

There has been a handful of times I've edited files within Symphony, mostly debugging something remotely or during a meeting etc. So convenient yes (in the sense it's available, not that in the sense that the editor is fully functional like a usual IDE), but best practice when working in teams, no, not really.

Aaa... I see now. Thanks a lot, guys, for the replies. BTW, I've tested the SymDeluxe. So far so good :-)

@brendo i do understand the VCS idea, but it's senseless for the lonely developer as i am. :-(

Take another look at it. Version control is not just for teams, it can be a powerful tool for you to snapshot the build at any point in time using tags, or to prove how much work you did in a particular day, or to rollback to a particular version of a single file.

You will never have to have file.backup.old or backup.zip again!