Search

It would be nice, if the version number of the currently installed Symphony build would be present and accessible somewhere in the interface. Maybe reintroducing the update alerts we had in version 1.7 would be a nice feature to see immediately if an install is up-to-date or not:

Alert

Agreed. It’s difficult to keep track of multiple installations.

Here’s a silly solution to the problem of not being able to view a version number: the Version Extension. As far as extensions go, it’s the most basic thing you could possibly build.

It’s based on my Configuration extension and Site Name extension. I thought there must have been a reason these extensions were not included with the new Symphony CMS site when the Downloads page was added. The Configuration extension is probably just way too dangerous. The Site Name extension just too trivial.

I developed these during the 2.0 beta 5 days. Anyway, I finally got around to seeing whether these extensions still work and they work just fine in Symphony 2.0.5. Now, there shouldn’t be an excuse for not knowing what version you’re running.

Thanks! These extensions should definitely be part of the submodule. I haven’t looked but does it make sense to combine the site name extension into the configuration extension?

Actually, it sounds like all three extensions should be combined…

It could be integrated on Symphony’s core and not an extension..

Don’t bloat the core! :-)

@michael-e You are right! I changed my opinion, it should definitely be part of the submodule.

When I created the Configuration extension, I thought it might be dangerous to expose that much information to all authors. Without author access controls, I thought it might be better to provide a standalone extension to at least be able to manage the site name. That’s the reason for the separate extensions.

Actually, it sounds like all three extensions should be combined

As an experiment, I’ve combined all three extensions into the Configuration extension. To give this a try, checkout the combo branch of the configuration repository. The configuration overview seemed redundant, so I’ve omitted this view. Since there is only the edit view, the Configuration menu now resides under the System menu.

Let me know if this works better for you.

Don’t bloat the core! :-)

@michael-e You are right! I changed my opinion, it should definitely be part of the submodule.

I’m sorry, but things like displaying the version number (or similar system and security relevant things) should definitely be part of the core. Anything else is bloating my extension folders, because I need a whole lot of extensions for just three lines of extra code here and there. So I hope you are joking …

That’s what makes the Version extension pretty silly. Like Nils, I would much rather see the return of the status widget we had in 1.7.

Adding version number to the system is definitely planned. It will likely simply be nothing more than a label with a version value. We’ve planned to put this in the settings page a good 4 months ago but it’s something we keep pushing back due to some new ideas we have regarding the whole settings page.

Status widget however will likely not be included as a core and the sole reason is due to the main functionality of the widget being a ‘phone home’ system that requires connection to the symphony servers to receive updates. We intend to use this incoming data as a way to gather statistical information but we feel that this should be an informed opt-in process.

We are not comfortable putting in non-essential components to Symphony.

The general rule of thumb with core v.s. extension is to consider whether a site can function without said feature. If it can function perfectly well without it, it should be an extension.

Thanks Allen for you answer. I would be great to see the version number in a new shiny preference page.

One thing I like to add though I perfectly understand your rule of thumb: Some things might not be necessary for a site to work but may nevertheless improve the core. Visually seeing if a site’s installation is up-to-date is one of those things that are not essential for running a site but that become quite important if we start talking about security and compatibility.

Concerning the “phone home” system: In my initial post I was not thinking about reintroducing the concepts of the pre 1.7 times (I remember petitions, one file installations etc…). I was thinking of a RSS feed on this site that returns the current version number. This could be grabbed and compared inside my own installation. So my own installation would not send any system relevant information, only a refferer. Of course, it should be an opt-in process.

One thing I noticed since the release of Symphony 2.0 is the rising number of tiny extensions. Those do nothing but adding a version number for example and need a lot of surrounding code to do so. The list of extensions I use becomes longer and longer and this is cluttering the server and the interface as the extensions area is not well suited for the management of long extension lists.

If we could include type as a separate field in the about function of the extension driver, this might open the possibility of being able to toggle views of each type of extension as a way to better manage the long lists of extensions.

Note: Sorry about hijacking this thread earlier. Any further interest in the Configuration extension (now updated to version 1.1) can be expressed in this thread.

A thought regarding update alerts:

Maybe reintroducing the update alerts we had in version 1.7 would be a nice feature to see immediately if an install is up-to-date or not

I’m a recent convert to Symphony (love it!) and have done a good amount of CMS business to business work. For some of my smaller clients I’ve used a WordPress configuration. WordPress has an update feature that alerts every with access to the back end that a new version is available and asks them to update. I generally delay updating a bit to see if there are any significant bug reports that surface. However, when my clients see the notification pop up it generates unnecessary phone calls and email for me. I’m not sure if this is what is meant by “update alerts”. I would suggest instead a simple text display of the version in operation.

I was thinking of reintroducing the icon (see first post) that have been in version 1.7 in the upper right corner. If an update is available the icon turns green but this should only be visible to admins.

I guess I never completely understand some of you guys and your desire to keep the software “light” or “bloat-free”, we’re talking about a CMS here. Why wouldn’t we want features that help us to do simple stuff like update the software, change some configuration options, allow member registration, add images, etc.?

I don’t care whether its in core, but the more “official” plugins the better. I really, really hate when you choose a 3rd party plugin and then 2 months later the guy is nowhere to be found and never updates the plugin again.

Wordpress may be getting a little on the bloated side… but it is also the #1 most used blogging software out there.

Let’s keep further discussion about core versus extensions in this thread:

http://getsymphony.com/community/discussions/26856/

To be honest, authors have no need to see this or to know whether or not the site uses the latest version. The developers, however, SHOULD know this as it’s vital information. Sometimes and update fixes a massive security hole that’ll save their bacon later on.

If you could make it so only developers get the alert to upgrade when they log in that, I think, would be best.

And it doesn’t need to be anything overly fancy, either. You could simply have the version number in the top-right with a little not next to it saying “Latest version is…” with whatever the version number being. That way it’s not blatantly going “UPGRADE NOW YOU IDGIT!”

We had a discussion about a dashboard a few weeks ago. Maybe the two could be combined…

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