Search

found it! set to 'no'
But it doesn't seem to affect...

still getting

Refused to display 'http://www.domain.com' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'

Maybe this is another setting?
Edit: I was getting this message after the introduction of the XSRF filter...

Can you log it on github? Thanks.

That's not a bug specifically, it's by design. You can override it by subscribing to FrontendPreRenderHeaders delegate and providing your own value for x-frame-options. Note that anything other than the standard will essentially 'disable' the protection.

Thanks, 'fixed' it!

Just a (very) trivial note: is it coincidence that the recent versions of ProcessWire are almost identical to symphony’s? :)

(EDIT: yet another typo)

Total coincidence, a very cool one though :)

how can i limit DS entries .. ? the input field gone in 2.4

You should see a fieldset labeled Pagination where you can set the entries per page.

Is there a reason why the version of Symphony you download from the main page of this website is pretty much unsupported? I think that the version pushed to the homepage for simple download/install should have functional extensions. Right now, even extensions maintained by Symphonists, even as basic as order entries isn’t supported. I believe the bsic download of Symphony should always have a good share of basic extensions available to it, and the latest version that is unsupported by the community should be something you have to specifically install. I think the homepage version should be 2.3.6 until basic extensions are supported.

Unfortunately we already added quite a bit of content to our install, so it would be a burden to downgrade, but I'm wishing I was on 2.3.6 so I could actually use my go-to extensions.

Symphony is maintained by a very small group of developers and it's up to us as a community to take care of upgrading extension. There is no company behind Symphony. Symphonists is an organisation to bundle the most important community extensions, they are not automatically updated by the core team when a new version is released (unlike extensions under the main Symphony organisation).

So if you find an extension that has not been updated for Symphony 2.4, you can do two things:

  1. If you know how to do it, update it yourself and send a pull request.
  2. If you don't know how to do it, pay someone to update it.

You complain that Order Entries hasn't been updated. This is actually wrong, it has been updated and the needed code can be found in the integration branch at https://github.com/symphonists/order_entries/commits/integration. It just has not been released yet due to the lack of feedback.

Unfortunately we already added quite a bit of content to our install, so it would be a burden to downgrade, but I'm wishing I was on 2.3.6 so I could actually use my go-to extensions.

I don't want to sound too harsh but it's actually your job to check if a version meets all your requirements first – and not to complain later if it doesn't. I really don't like this kind of comments because they put the blame on the community.

Personally, I'm happy that Symphony is still evolving and I'm happy that there are still so many people supporting the development in their spare time. And it's up to us all to let the development of the core and its extension continue.

I'm raising an issue, but I believe it’s being disregarded at as a complaint.

My point is, I've worked with Symphony many times and one area it lacks is reliability/dependability. I believe knowing that I'm downloading a generally unsupported version should be made clear. The choice should be mine to get the one "everybody's using" vs. "the one that just got finished."

I'm not saying the community needs to work harder. I'm suggesting that a way to make Symphony, as a consumable, more mature is to release only generally supported versions for the users at large.

What makes you think that Symphony 2.4 is a generally unsupported version? Because symphonyextensions.com currently doesn't list the latest version? That's a known issue of the site, not one of Symphony, see this conversation: https://twitter.com/brend0/status/471883634316550145

My point is, I've worked with Symphony many times and one area it lacks is reliability/dependability.

I hate to say this, but I totally agree (although we need to differentiate between a few things).

I'm suggesting that a way to make Symphony, as a consumable, more mature is to release only generally supported versions for the users at large.

Done. That version of Symphony is currently Symphony 2.4.

But there are several problems with it (not blaming anyone, by the way).

  1. It's still very buggy.
  2. Extensions maintained by the core team (which in most cases is just Brendan, Nils and John, who are not getting paid for working on Symphony and do this in their spare time) are not always up to date with the latest core version.
  3. Symphony only seems to live on GitHub these days. The entire ecosystem (getsymphony.com, symphonyextensions.com) is largely outdated and no longer regularly maintained.

I believe the bsic download of Symphony should always have a good share of basic extensions available to it, and the latest version that is unsupported by the community should be something you have to specifically install. I think the homepage version should be 2.3.6 until basic extensions are supported.

Symphony 2.4 was in development for quite some time (104 days) including reasonable beta and release candidate cycles.

People usually don't get paid to create or maintain extensions on a regular basis, so stuff is often not updated until it's needed again in a new project.

If extensions aren't updated for 2.4 by now, they are either not actively maintained anymore or currently not needed in any new project by their developers.

Right now, even extensions maintained by Symphonists, even as basic as order entries isn’t supported.

There's a common misconception about Symphonists extensions. These extensions were abandoned by their developers. The Symphonists organization on GitHub is more of an "orphanage" for these extensions, to keep the code publicly accessible for anyone who wants to use, update or "adopt" these extensions.

Symphonists is an organisation to bundle the most important community extensions.

I think that's exactly what's causing the problem. Calling these extensions community extensions suggests they are regularly maintained and raises expectations. Also, the term organization might be misleading. This is just a community account on GitHub, not an actual organization.

I don't want to sound too harsh but it's actually your job to check if a version meets all your requirements first – and not to complain later if it doesn't. I really don't like this kind of comments because they put the blame on the community.

The problem is, if you put a product out there (even if it's free) and build a community around it, people have expectations. If you continue to work on someone else's product and put new releases out there, it's your responsibility now.

Personally, I'm happy that Symphony is still evolving and I'm happy that there are still so many people supporting the development in their spare time. And it's up to us all to let the development of the core and its extension continue.

I agree. But we also need to make clear to people that Symphony as a full fledged project with an actively maintained ecosystem is mostly dead.

There are a few people left who continue to work on the core system, and there are still developers (including myself) who use it regularly and contribute bug fixes and extensions when it's needed for a specific project.

I think we all agree that if Symphony shall have a future, it needs a new base – technically and organisationally. This has been stated a lot of times and you know my opinion here, Jens.

Regarding Symphony 2.4: we have completed an enormous list of issues on Github and I think Symphony 2.4 is a lot more mature than previous releases. There have been multiple beta and release candidate circles and all changes have been documented and announced properly. So I don't think Symphony 2.4 and its release are a problem. All "core" extensions (I don't like that term by the way) have been updated. Remote Datasource that you mentioned above has just not been released by mistake, but the update has been available on Github since the release of 2.4.

The extensions under the Symphonists account are the actual problem as you said, because people think they are officially supported. They are not.

The problem is, if you put a product out there (even if it's free) and build a community around it, people have expectations. If you continue to work on someone else's product and put new releases out there, it's your responsibility now.

Yes, of course. But if an extension is not working this is not a problem of the core. And that's why I said that it's everyone's responsibility to check compatibilities first.

Symphony only seems to live on GitHub these days. The entire ecosystem (getsymphony.com, symphonyextensions.com) is largely outdated and no longer regularly maintained.

That's true but it's has not been an active decision. The problem is that all main developers of Symphony community sites have left the community for different reasons (new jobs etc.). So we still have a house but not all the keys.

The idea two and a half years ago was to build and maintain the community sites openly on Github so that they are not a single person's responsibility – that's why Factory was created. I actually don't know why work stopped before this was finished. Suddenly, everyone had gone.

This has been stated a lot of times and you know my opinion here, Jens.

Sure. Just wanted to make it more transparent for anyone else. And again, I'm very thankful and not personally blaming anyone.

Regarding Symphony 2.4: we have completed an enormous list of issues on Github and I think Symphony 2.4 is a lot more mature than previous releases.

True, but it also introduced a lot of changes and new issues, so 2.3.6 was actually more mature and stable in that regard (as with all major and minor releases).

All "core" extensions (I don't like that term by the way) have been updated.

Also, Select Box Link doesn't seem to work properly with the new core publish filtering (maybe just a minor issue, but still, these things don't exactly scream reliability).

Remote Datasource that you mentioned above has just not been released by mistake, but the update has been available on Github since the release of 2.4.

Sure, but that wasn't clear a few days ago when I started working on a new project using 2.4.

It's also not clear in such cases if the updates on integration are complete and ready to use, or still a work in progress.

maybe just a minor issue, but still, these things don't exactly scream reliability

I agree. But generally these are not issues of Symphony 2.4 – they are issues Symphony is having since years. The general lack of a monetary resources and staff in general has been a problem since 2011 and it has been discussed very often.

While I'm contributing to Symphony I actually don't know who maintains the project in general. I don't know who is currently hosting this sites, who has admin access to it etc.

And we are making baby steps to solve problems in the codebase and those involved know that it actually needs a fresh start to get rid of the major conceptual flaws. But we don't have the needed resources.

So, Jens, what you are complaining about is not the state of Symphony 2.4 because this hasn't got worse compared to the earlier versions. You quarrel with the organisational state of the project. The missing perspective. And yes, this is an unsolved problem. It's about ownership, responsibily, leadership and about future-proof concepts and ideas.

By the way, if you'd like to know how I'd proceed with Symphony:

  1. I'd reduce the community sites to the minimum needed, using existing services whereever possible (Github wiki, issue tracker, external discussion services).
  2. I'd create a concept how a modern Symphony should look like.
  3. I'd try to fundraise the initial development of this new Symphony

The problem is that – besides money – you not only need ideas but also people with the skills to implement them.

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