Symphony.

We now have a Release Candidate 2!

After the release of Symphony 2.3, Symphony 2.3.1 aims to continue to streamline a user's experience in the backend and offer a more flexible, stable and speedy core.

This beta contains some new features that have been discussed and in the pipeline for a long time, so enjoy!

New features

• All core fields can now be required or not (that means the Checkbox, Taglist and Date fields learnt this superpower).
• All entries now track their modification date. This now means you can filter, sort, include or output parameters for an entry's creation date and modification date.
• The upload field no longer throws an error when you upload a file that already exists, it simply renames the file (by adding _1) and allows you to carry on. Nice.
• The index page supports parameters without requiring the page handle, making URL's such as example.com/:param/ possible without an extension.

Read the full release notes

Download

• Via Github
• Via Download

As always, if you encounter any issues, please post them on the issue tracker. If you have questions or are troubleshooting, use the forum, we're a pretty friendly lot :)

Attachments:

symphony2.3.1beta1.zip

These are some beautiful field and section changes. Can't wait til this gets a full release.

Very nice, glad to see root level parameters. Looking good.

Shouldn't the system:author also be included in the XML output elements list?

If we output the system id as a parameter we can chain DSs and match the entry id from $ds-section.system-id using XSLT.

But we cannot do the same with authors since they are not in the entry's xml output (except if we output an author field, but this may not be the same as system author).

At this time, we can output and chain the system authors, but not easily match them like entries system ids.

We only missed two issues for this release, and only a few dates later that originally expected! I think that's a round of applause for everyone involved in this release so far.

Also, great big thanks to Brendan, who is on holiday and still working!

Wow, this eliminates the need for 3 extensions I use often enough. Like always, great work guys! Round of applause indeed.

Also, great big thanks to Brendan, who is on holiday and still working!

He's going to get a lot of free drinks in Boston :-)

Wow, this eliminates the need for 3 extensions I use often enough.

Which three?

I can guess at two, Required Checkbox and Date Modified.

I can also guess at URL Router or Root Page Params.

The URL Router will be re-addressed to remove the Root Page Params feature-set to return it back to simply routing URLs.

I can also guess at URL Router or Root Page Params.

or Improved Page Resolve..., i wonder which extension is used... :-)

Good guesses.

Which three?

For me: Unique Upload Field, Improved Page Resolve, and Date Modified.

This goes to show that I can never be arsed to link to the actual extensions I mention.

I would not have thought about Unique Upload Field!

I am not sure about the Unique Upload Field. It also has the benefit to prevent browser caching if you re-upload a file using the same filename. How does S 2.3 behave in this situation?

it seems like it renames it. So no need for cache... as it would have a different name. Haven't tried it yet though

The uploaded file is only renamed if there is an existing file with the same name. There are two ways to replace a file, with a subtle difference, but it's an important one.

Replace

1. An entry has an upload field and the file is called example.jpg
2. 'Remove File' is clicked and then a new version of example.jpg is chosen to be uploaded
3. Click Save Changes
4. This will rename the image to be example_1.jpg (and remove example.jpg), because at the time of upload, example.jpg is still on the filesystem.

Remove

1. An entry has an upload field and the file is called example.jpg
2. 'Remove File' is clicked and then Save Changes is also clicked
3. A new version of the file, example.jpg, is uploaded
4. The filename will be unaltered, because example.jpg was removed from the filesystem when Save Changes was clicked in 2)

So depending on your workflow, Unique Upload Field may or may not be required.

One of the features I love about the unique Upload Field is the clean-filename output. Comes in handy most of the time, will the core upload now have something similar?

Thanks, @brendo, for explaining this. Sounds fair, but it means that the author is responsible for the filename.

Thought I'd repost my comment from Github issue #1092 for those who don't watch the repo. This is a new feature for how we handle missing extensions, which is one of the most common causes for newbies to post in this forum. This is not in Beta 1, but will be in Beta 2.

So here we go, this commit does the following:

• If an extension provides an extension.meta.xml file, and it's @id does not match the folder name, it will no longer appear in the Extensions listing. This enforces the schema @nickdunn wrote.
• If an extension has previously been installed, but for whatever reason the folder no longer exists, Symphony will error out to a new error template, usererror.missing_extension.php.
• This page allows a user to uninstall the troublesome extension, or considering 3 years of forum posts, give the option to rename the most likely extension folder to the correct name. If the rename fails, the user is notified and asked if they want to uninstall the extension.
• The most likely folder is determined using PHP's similar_text function. We iterate over the EXTENSIONS directory comparing the folder names with the correct name (determined by the handle that saved in sym_extensions). If the comparison is above 75%, that folder is added to a $matches array. After iterating through the directory whatever the most likely (ie. highest percentage) match is shown to the user.

This needs testing and general feedback. A big thanks to @alpacaaa for kickstarting this off 5 months ago ;)

@brendo even though I’m only 1/8th of a programmer … I could imagine the similar_text function to be error-prone in situations where you have very similar extension folder names, at least it is not failssave. Why not simply parse all folders in the extension folder for their extension.driver.php in order to find the proper folder, and thus rename it according to what’s defined in there?

animaux: While I don't have a problem with using similar_text as it's only supposed to work as a suggestion what you're proposing is actually a good idea.

To my knowledge this wasn't possible with Symphony 2.2 as the extension class name was derived from the path. If the path was wrong the class simply couldn't be instanced (you may know a list of files but not a list of classes being known to the system).

With Symphony 2.3, the id-Attribute in extension.meta.xml must match the folder it's being installed to. So basically a list of all extensions for which those two values don't match should be easily retrievable, skipping the need for similar_text altogether.