Search

Brendo, I think the current session code only adds a benefit for a very small minority of websites (those that are load-balanced with a shared mysql pool). For those websites a sticky balancer - which leads a user to the single server containing its session - is a good temporary solution. This will probably be faster, too.

My vote would be to remove the custom code for now, and let the hosting platform choose what fits best. Then for 2.4 we can implement a solution that will actually work.

Was just stumbling upon http://phpcr.github.com/ and thought, with regards to xml sections, this could be interesting for you.

Just my usual ramblings on your release schedule (thanks a lot for all your work anyway)...

I'm currently running some production sites on beta- and rc-versions due to some nasty bugs in the last stable release.

For projects I'm currently working on, I also have to use an unstable dev-version of the members-extension because the last stable members-release doesn't work with latest Symphony integration.

Since the issues you're currently holding off for aren't specifically new in Symphony 2.3.2, wouldn't it be better to release smaller bug-fix updates more often, even if not all issues are fixed in each update?

In my opinion, it's better to have a smaller update every month that fixes some of the issues, than having to wait three or more month for one big update that fixes all issues (and also introduces new ones because things have changed in a major way internally or new features have been added).

I have to do client work between stable releases, and I don't feel very comfortable using the integration branch and work-in-progress-dev-branches of extensions for new projects. It's also very time consuming to dive into the code every time to fix smaller issues during client work.

Jens, this was discussed this morning on github and consensus was reached that a release will be packaged up asap by Brendan for these exact reasons.

I would hazard a guess that it will be released by the end of the weekend.

This does raise a question that I want to re-open (as it as discussed a couple of years ago) to the working group about our release schedules and version numbering. I will be contacting the WG separately about this to try and streamline the process, although last decision will remain with Allen and Brendan on any changes to the process.

Of course the discussion will be visible to the public using Symphony, but I will try and keep noted opinions to the working group who contribute most to the core.

I do agree somewhat with your ideas, we just have to agree them officially.

The only issue I see with this is resources. Often the project goes on it's own for weeks at a time while the contributors are busy, so trying to release each month may lead to a reduce in quality we can't be guaranteed the code has been tested as thoroughly. It adds a workload to myself to maintain, update release notes and generate documentation monthly, which is definitely doable but just something to be aware of.

Looking at the history, the 2.2.x branch averaged a release every 2 months. The 2.3 release hasn't been as frequent (6 months, 5 months and 2.3.2 will be 5 months) and that's definitely attributed to a loss of main contributors and the fact I went traveling for 6 months.

Regardless, I see your point, there's been some bugs in recent releases that have been unacceptable and should have been picked up earlier.

Here's to a more frequent cycle moving forward :)

Regardless, I see your point, there's been some bugs in recent releases that have been unacceptable and should have been picked up earlier.

Actually, my point was that a lot of bugs have been fixed for month in integration, but a lot of other stuff has been added too that broke compatibility (with members, for example) and needs more testing.

Maybe it would be better to differentiate more between bugfixes and general improvements (changes), release bugfix-only updates more often and hold back other improvements (changes and additions that need more testing and break compatibility) for larger releases.

John's proposal is pretty much in line with what I mean.

I'd like to announce the release of Symphony 2.3.2RC2, which contains fixes that have been raised on Github. Due to the number of fixes, a RC2 has been packaged rather than a final release to ensure that there are no show stopping bugs. If there are no show stoppers, 2.3.2 final will be released on March 24th.

A big thanks to all those who contributed with patches, discussion or who raised a ticket!

I have a minor little problem with Section Entries. The sort ascending and sort descending doesn't seem to work.

Glen, if you navigate to System > Preferences, do you get a notice at the top of the screen about your config file? I've seen this occur if the config file is not writable.

You are absolutely correct. Thank you. I've got about 20 extensions operating with 2.3.2RC2 and so far it's working well.

New problem: I receive this error when I'm updating the page: ...symphony/blueprints/events/info/membersactivateaccount/ 'An error occurred while processing the form.'

The logs say: [error] [client ipaddress] PHP Fatal error: Undefined class constant 'STATUSOK' in /var/www/rootdirectory/extensions/members/content/content.events.php on line 68, referer: http://rooturl/symphony/blueprints/events/info/membersactivate_account/

Is this related? Will this affect the members-activate-account page?

Nice, spot, this is actually a bug in the Members extension which has not been fully updated to 2.3.2RC2 yet. I'll get on it ASAP. It's to do with the abstraction of the page headers to the Page class instead of being on the AjaxPage class.

Release 2.3.2 looks fantastic. Good job! I'm very anxious to put it into production.

I'm starting to pick up how Symphony works. I'm not a developer and I appreciate the Symphony group's work. 2.3.2 seems very stable to me, but others seem to be having problems. I don't know if this is the place, but I'd like to try to shed some light on how to have a stable Symphony experience.

I feel like I've been through what seemed like instability. Part of the problem with being new is that I don't know what's important. I originally thought that choosing the newest stable version and adding extensions from the Compatibility Matrix was all it took. When I started downloading extensions it was difficult to match these two. Git and github are the key. You must learn git to do this.

I think it is difficult to upgraded an operational website. A transition from 2.2.5 to 2.3.2beta1 (now 2.3.2) takes some time because of the extensions which in my case included: the core eight, Email Template Manager 4.1 using the 2.3x branch, Members 1.3beta2, Image Index Preview, Import/export CSV, Order Entries, Preview Textarea, Publish Tabs, Reflection Field, Resave entries,Select Box Link Field, Admin Override CSS, and Client Logo.

I found that the most stable way 2.3.2 will work is with the two integration branches. Spend time to learn how to download and use the integration branches using git and github. As an introduction, the zip download is great, but when you start mixing in extensions you have to be very careful to match the extension version to the corresponding core. Also note that RC or beta versions aren't as forgiving for poor XSL code, etc.

I found the git description in this article to be very helpful. I would like to expand it more to include descriptions of what success for each command looks like. The book Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development shows commands and results.

With regards to dependency management: Are there any considerations on using Composer for extension installation for the future?

For those who don't know composer: It's the de-facto package manger for php projects and it works great with vcs such as git (even on private or local repositories). And there're other benefits than dependecy management when using composer e.g. class loading (psr-0 an classmap), file inclusion.

It's not suitable for the current state of symphony as is requires php 5.3+, but since this is the last major release that supports 5.2 I thought it's worth mentioning it.

With regards to dependency management: Are there any considerations on using Composer for extension installation for the future?

I support this idea.

iwyg As a user and not a developer, what would the process be to use Composer?

Edit: I mean designer ... not user.

Well, it depends on how you define "as a user".

Imagine Symphony using composer for the core installation, the process would be something like:

php composer.phar install

While that sounds developer friendly, that doesn't sound very designer/user friendly.

@iwyg whilst concept is interesting before going with anything like this at the core it would probably make more sense to have it as a separate stand-alone extension.

Then other developers might be able to use this in other extensions to list dependencies which are not in the core. Long-term if proven valuable and easy to use I don't see why it couldn't make its way.

I used Composer for the first time over the weekend while looking at Laravel. As long as you have command line access to PHP (probably not a problem for the kind of user Symphony is aimed at?), it's easy.

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