Symbiote

Engineer the web, together.

Symbiote news

Keep in touch with what we're up to.

RSS available too if that's your thing!

Yes, even Firefox gets it wrong

Posted 16 Aug 2017

Not so pixel perfect in Firefox

Imagine for a second, that you're trudging through the inconsistent waters of frontend development and you've incredibly close to finishing off a piece of work. You test in Internet Explorer 9+ and pray. The gods smile on you as you haven't hit an browser-specific bug. You then move onto Safari for Mac and iOS. The skies are clear and you're so close to being done when suddenly... tragedy strikes.

You test in Firefox and see that various parts of your layout are off by a couple of pixels for seemingly no reason. "Why Firefox? Why has thou forsaken me? I thought you weren't like Internet Explorer!" you scream, perhaps also throwing a few profanities around for good measure. After you let the frustration wash over you and calm down you'll probably end up adding a fixed-height on all offending elements so that the off-by-one bugs are "fixed".

But what the heck happened? This problem is not at all new, in fact, with this bug now passing 11 years of life. The issue lies with rounding up the calculated height of text, rather than down when using ems / rems on the line-height property. The only way to not hit this bug is to use fixed pixel sizes with the line-height property, which isn't really feasible if you want to support zooming in Internet Explorer 9.

You can run the following JSFiddle to get the calculated height of a div containing text with the offending line-height styles: https://jsfiddle.net/63v5vpaL/9/

As you can see, every browser that isn't Internet Explorer 6 or 7 will consistently render the div and have a height of 146px. That includes Firefox on the iOS 6S Plus.

Tested browsers with 146px height (rounded down):

  • Windows 7
    • Internet Explorer 8 (changed REM to EM for test purposes)
    • Internet Explorer 9
    • Internet Explorer 10 (Full Version: 10.0.9200.17229)
  • Windows 10
    • Chrome 59
    • Internet Explorer 11 (Full Version: 11.1358.14393.0)
    • Edge 38 (Full Version: 38.14393.1066.0)
  • iOS 5S
    • Safari
    • Chrome
  • iOS 6S Plus
    • Chrome
    • Safari
    • Firefox
  • Nexus 5X (Android 4.2)
    • Chrome
  • Mac OS Sierra
    • Safari 10.1
    • Chrome 59
    • Opera 46
    • Yandex 14.12
  • Mac OSX Lion
    • Safari 6
    • Chrome 49

Tested browsers with 147px height (rounded up):

  • Windows
    • Firefox 54 (32-bit)
  • Nexus 5X (Android 7)
    • Firefox
  • Mac OS Sierra
    • Firefox 54
  • Mac OSX Lion
    • Firefox 44

Old Internet Explorer shoutouts:

  • Internet Explorer 6 has 154px height.
  • Internet Explorer 7 has 148px height.

Renaming an organisation

Posted 18 Jul 2017

Changing company name?

Ever had to rename an organisation and its digital footprint?

When changing a corporate name, there's a lot of things that need to be done behind the scene. Branding and domains, regulatory bodies and government registrations. For us, we also have a sizeable open source footprint that covers a full and rich history of work done by current and former staff. Not to mention that some of those modules are among the most widely used in the SilverStripe CMS landscape. 

Our goals were reasonably straightforward, but also gave us the opportunity to do some housekeeping and restructure our module sets. 

  • Move all "core" modules that we actively support from their current randomly assigned structure (username/modulename, silverstripe-australia/modulename, silverstripe/modulename) to a consistent format: symbiote/silverstripe-modulename
  • Create "symbiote-library" as a holding organisation to highlight code that we've created, and use, but don't actively promote as being supported. We'll still take PRs, but not be as responsive. 
  • Separate the modules as needed into "symbiote" and "symbiote-library" - both at the GitHub and Composer / Packagist level
  • Rename the core sets we use for customer implementations - "basis" => "seed", "basis-community" => "collab", and the naming of our AWS modules to "thrive".
  • All the while not  breaking our existing projects' build processes; old composer.lock references should continue to work. 

When there's hundreds of modules involved, you can see how things could quickly go wrong... Thankfully, a couple of very important features of GitHub and Packagist assisted the process

  • Re-assigning a repository in GitHub from one organisation to another will automatically create redirects for you
  • Abandoning a module in Packagist and pointing at its replacement means composer will alert users pretty quickly of the changes

One approach that was considered was to checkout all the repositories, make appropriate composer changes, and simply push the changes up to the new organisation repository. While it would have worked out, we would have missed out on the automatic redirection that GitHub could do if the repo was transferred across - and meant that our goal of not breaking existing projects may have failed depending on project configuration. As we were keeping the new organisation name under wraps, we were also limited somewhat in the amount of activity we could do without creating unwanted attention. 

After much testing on dummy repositories, the final approach ended up being

  • Clone affected repositories - it can be very helpful to remove the upstream remote after doing this to ensure you don't accidentally push your pending changes before it's ready. 
  • Change composer vendor strings, modify any namespaces.
  • Replace references to old company names throughout code - you'll be surprised how many references to user@email.com in file @author headers exist....
  • Update "installer-name" variable;  many of our modules went from "name" to "silverstripe-name", meaning their install path changed
  • Bump the composer version - both in composer.json branch aliases and git tags. We couldn't find a definitive source that stated whether a vendor name change is considered a non-backwards-compatible change or not. Depending on the number of dependent module changes or actual code changes, most modules received a major version bump (it's just easier...) but some of the smaller ones were minor version bumped. YMMV!
  • Importantly for existing project support - update the installer-name on "stable" branch lines (ie queuedjobs has both 'master' and '2.10' branches being actively used). The way composer manages these means that new module name on packagist is "symbiote/silverstripe-queuedjobs". It will still pick up that it has a 2.10 code line as a 2.10 branch exists, but that code line does not  have an installer-name in its composer file, meaning it would install incorrectly...

All those activities could be done prior to the "rename day" itself (except we only caught the final point after beginning...). On the day itself

  • From origin repository, "Transfer" ownership using GitHub's UI. We considered automating this, but the manual approach removed an extra layer of code we'd be looking to manage and test.
  • Push from the local repositories (remember, github will automatically redirect the push). You can do this push prior to the transfer if you're not wanting to leave things to redirect magic. Remember push --tags !
  • Submit the new module repository to Packagist
  • "Abandon" the old module in Packagist
  • Run a composer create-project -s dev symbiote/silverstripe-modulename to confirm it made it through with new dependencies. If you have a module with multiple dependencies (ie, we could use Seed for this), save yourself some keystrokes and run against that once done. 
  • Update all github organisation access details - depending on how your permissions were set up, the transfer will not necessarily bring through all associated user rights. 

Unfortunately, this process does lose the old module name's statistics - if those are important to you, best record them elsewhere :). 

Whilst we haven't moved all modules over just yet (personal staff modules are being re-vendor'd only), the company managed ones were moved over the course of several hours with little fuss. There have been a few reported breakages (quickly resolved!) but on the whole, it was smooth. A+ would never do again!

SilverStripe Australia announces corporate name change to Symbiote

Posted 30 Jun 2017

SilverStripe Australia announces corporate name change to Symbiote

SilverStripe Australia, the Australian arm of open source CMS vendor SilverStripe, announced today that it is changing its corporate name to Symbiote.  The name change reflects the success and growth as a service delivery team that focuses on engineering high quality solutions, and encompasses an ongoing commitment to collaborative solution delivery.

"We want to focus on the process of designing and implementing specific solutions in collaboration with customer teams. SilverStripe CMS will remain our primary content delivery solution, but this gives us the opportunity to diversify in the products offered around that" said Managing Director Owen Windsor.

"Our team have worked hard to build SilverStripe brand recognition throughout Australia. We have a large number of modules out in the open source community, which we're dedicated to supporting ongoing. We're excited to continue working with SilverStripe as premium partners"

It won't be long before a new SilverStripe office opens on Australian shores. CEO Sam Minnée confirmed "We’re committed to the Australian market, and we will be building a team in Melbourne to support our partners here with SilverStripe Platform.

Owen and the team at Symbiote have done great work pushing SilverStripe’s capabilities and growing its recognition. We look forward to continuing work with them as a partner, and are excited about this growth of the SilverStripe ecosystem.".

Please read this update for more information about modules created by SilverStripe Australia, and their changeover to Symbiote.

About Symbiote

Based in Melbourne, Symbiote is a national leader in the development and implementation of SilverStripe CMS based solutions with 7 years experience as a primary service provider to a wide range of government, corporate and education providers.