Search

Symphony 2.2 is just around the corner, so now is the time for extension developers to update their code and test. If you’re an extension developer then you should:

  • download and install Symphony 2.2RC1 (the zip will do)
  • find your username on the extension compatibility list and feel the pain when you see you haven’t checked compatibility for such a long time
    • clone your extensions from Github into your 2.2RC1 build and start testing!

Here are some common things to look out for when updating extensions for Symphony 2.2. These were the obvious ones that I had to perform multiple times with my set of code.

  • search for references to “_Parent”:
    • $this->_Parent->Database replace with Symphony::Database()
    • $this->_Parent->Configuration replace with Symphony::Configuration()
    • $this->_Parent->saveConfig replace with Symphony::Engine()->saveConfig
  • remove use of private members such as $entry->_data['id'], replace with $entry_>get('id')
  • check you’re using duplicators properly (if you use them at all)
  • check the Symphony log file for common problems such as “Argument #2 is not an array” errors when using foreach on arrays (be sure to check is_array(...) first!)
  • check that fields render nicely in publish forms. If you rely on <span> elements having the default grey background and passing, they’ll now need a class of frame
  • rename CSS and JS files with the preferred format: [extension_name].[section_of_backend].js for example order_entries.publish.css
  • if you write stuff into the DOM from PHP and then later collect with JavaScript, you should be using the Symphony.Context JavaScript object

When you make your changes and release a new version, remember to:

  • update the version number and build date in both your README and extension.driver.php
  • push commits to Github and tag your new version too
  • update the extension on this website (version and build date)

You should also make sure you’ve read the following, which explains in full:

If you’re having problems, then ask away in this thread, or suggest a time and timezone and we can try and collaborate on IRC.

Let the commit wars commence :-)

Nice tips. Right on time …

Quick CSS tip: if you want to target Symphony versions pre- or post- 2.2, here is a solution.

The following means “pre-2.2”:

body > form <everything else>

The following means “post-2.2”

body > #wrapper <everything else>

I hope this is useful ;)

body > #wrapper

Can be even simpler (and more efficient) as:

#wrapper <everything else>

No need for greater specificity once you use an ID selector :-)

Doh, that’s the problem when you don’t double-check your own comments! Thanks ;)

No need for greater specificity once you use an ID selector :-)

Unless there’s a possibility for the existence of a #wrapper element in pre-2.2 just not as a direct descendant of the body element. I don’t know?

Unless there’s a possibility for the existence of a #wrapper element in pre-2.2 just not as a direct descendant of the body element. I don’t know?

Luckily not :) That’s why Nick is right.

One might consider a more “unique” name if using IDs. On my websites I would call this body-wrapper. This reduces the risk that the same element will occur twice — in the case of the Symphony backend another wrapper ID might for example be introduced by extensions.

in the case of the Symphony backend another wrapper ID might for example be introduced by extensions.

In my opinion, extensions should namespace their additions. Then it’s not a problem.

Yep I agree with Nils.

I agree: They should. :-)

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