Symphony.

It looks like there is a lot of activity on GitHub. It looks like version 2.1 is imminent. If so, how can we help test?

I like the new XML configuration files, such as the db.xml file:

<?xml version="1.0"?>
<configuration>
    <driver>mysql</driver>
    <character-set>utf8</character-set>
    <character-encoding>utf8</character-encoding>
    <runtime-character-set-alter>1</runtime-character-set-alter>
    <disable-query-caching>no</disable-query-caching>
    <host>localhost</host>
    <port>3306</port>
    <user>root</user>
    <password>root</password>
    <db>projects_symphony_2.1</db>
    <tbl-prefix>sym_</tbl-prefix>
</configuration>

Curious about what you’re up to, I’ve cloned Allen’s repository and poked around a bit. I was able to establish a connection to the database by copying the db.xml.example.xml file and renaming it to db.xml.

Then, I copied the .htaccess file from a Symphony 2.0.7 install. That gave me access to the login form. But attempting to login resulted in the following error:

Table 'sym_symphony-working.sym_users' doesn't exist

So, I renamed the sym_authors table to sym_users and copied data from another install. Then, I was able to successfully login, I think. But I encountered a Symphony Fatal Error.

DirectoryIterator::__construct(/Users/stephen/Sites/sym/symphony-working/workspace/sections): failed to open dir: No such file or directory

There was no workspace. So, I copied a workspace from another 2.0.7 install and created a sections directory. Bingo! I have an almost working Symphony 2.1 install. Cool!

Looks like there’s still a bit of work to do on the installer.

There was one more error I encountered:

RecursiveDirectoryIterator::__construct(/Users/stephen/Sites/sym/symphony-working/workspace/views): failed to open dir: No such file or directory

This one was solved by adding a views directory to the workspace.

Gotta say, I’m loving the new Extensions page.

• All
• Core
• Data Sources
• Fields
• Other

I also like the user name and logout at the top of the interface.

Well, I guess that’s about as far as I can go without the ability to create sections :-(

file_get_contents(/Users/stephen/Sites/sym/symphony-working/symphony/template/section.tpl): failed to open stream: No such file or directory 

You’re taking the mystery and intrigue out of our sneak peek! Actually, it’s all good.

We’re not quite ready to discuss the 2.1 stuff just yet, but we’re hoping to release a working alpha build some time soon.

Right now, the 2.1 codebase requires a bit of manual jigging to get it to work. I’m surprised you got that far bauhouse!

So what about 2.0.8?

2.0.8 is coming before 2.1 alpha release.

Great. Thank you, Allen.

You’re taking the mystery and intrigue out of our sneak peek! Actually, it’s all good.

Sorry about that. I get excited when I see things happening in the public repos. I couldn’t wait to try it out. You’ve obviously been working hard behind the scenes.

I’m surprised you got that far bauhouse!

I didn’t expect to get that far either. I’m looking forward to the alpha build.

I’ve seen that the components have been splitted up into separate backend pages (that feels a bit like 1.7 and I like it).

It would be great if there was an option to tag data sources, events and utilities that could be used to group/filter the overviews (maybe using that tabbed interface that on the extension page). I normally end up with long names for data sources following a strict naming scheme to be able to keep track of things as the list currently is sorted alphabetically. A tagging feature could simplify the component management.

And another wish: If you want to push localisation support a step forward with Symphony 2.1 it would be great if Symphony would use strftime() for all interface related date and time information. It currently still uses the date() function which does not support local formats.

Multilingual support for front and back end from the off would solve my big head ache!

It would be great if there was an option to tag data sources, events and utilities that could be used to group/filter the overviews.

Maybe this could work as an extension?

maybe using that tabbed interface that on the extension page

It’s very easy for an extension to plug into that area underneath the <h2>, either for tabs or filter fieldsets or whatever. Have a look at the appendViewOptions() method in class.administrationpage.php around line 501. Now, bear in mind I’m new to programming, so this may not be the most elegant thing in the world, but it can take either a named ‘subnav’ array, which will render tabs, or another XMLElement object like a fieldset. The idea is to give us a way for extensions to add this sort of thing to the UI (think Publish Filtering extension, for example) in a way that’s standardized and consistent.

Thanks for your answer, Craig. The thing is that in my opinion the management of core content should be a core task and not one of an extension (I know it’s possible but that argument is not strong enough for me). If it’s an implemented feature for extensions why not make use of it throughout the system?

There is a really bad thing about extensions: They are never taken care of as much as the core is. This is true for the core extensions as well.

How do you handle large lists of data sources, events or utilities?

The thing is that in my opinion the management of core content should be a core task and not one of an extension

The Components page could do with a rejig perhaps, but I’ve found when I have a load of assets that a simple, sensible naming convention solves the problem. I’d be loath to individually tag and filter a list of Data Sources; to me it solves a problem that doesn’t exist.

Even a list as long as this, sensible labelling means things are still obvious and findable.

I still vote for grouping DSes by the Section they’re pulling from. :-)

The thing is that in my opinion the management of core content should be a core task and not one of an extension

But the distinction to be made here is not about whether we’re managing core content, but whether we’re talking about a core functionality. If it’s not something that the VAST majority of users will need, then arguably the functionality is not important enough to include in the core. I might want to be able to color-code my data sources for easy scanning, but just because it’s dealing with data sources doesn’t mean it should be in the core. I think we’d all agree that it would need to be an extension (and a silly one at that).

There is a really bad thing about extensions: They are never taken care of as much as the core is.

This is something we will address. Two points here. First, part of the push to abstract things into extensions is that it’s much easier to fix and update extensions than it is to roll out new Symphony releases. The goal from 2.1 on is to have a very lean, very solid and stable core that doesn’t change a whole lot between minor point releases. As much as possible, we’d like to shift the burden of change onto extensions, because we can update those on an ongoing basis and protect the core.

Secondly, we are planning to build more robust extension management into 2.1—the beginnings of which you’ve seen with the tabbed and categorized interface. At the very least, we’ll be talking about smart update-checking from within the Symphony back end, but we’d love to hear other ideas.

I still vote for grouping DSes by the Section they’re pulling from. :-)

Yeah, this is the sort of UI thing I’ve really wanted to tackle, but doesn’t fit in the scope of 2.1 because it would, if done well, require a significant overhaul. The basic gist of it is that I don’t think we do a good enough job of exposing the relationships in Symphony and making them actionable. Seeing what Pages/Views are using DSes and Events, or where Utilities are included in templates… being able to spin off a DS or Event right after creating a Section… attaching Events and DSes to Pages/Views from their own editors… that sort of thing.

I believe the plan is, for the next major release, to have an open UX/UI development process where we can kick ideas around and hash these sorts of things out. So start putting all your ideas into a little box somewhere ;)

Even a list as long as this, sensible labelling means things are still obvious and findable.

Holly batman!