Our experience using CWP 2.0

The following outlines our experiences using the Common Web Platform 2.0 (CWP 2.0) during the development of the Practice Centre site for Oranga Tamariki.

We were one of the first projects to use Recipe 2.0 of CWP and began working on it while it was pre-release. Therefore there were some aspects that were untested and a series of teething problems which were all fixed during our working on this project.

The teething issues included:

• An issue with the the internal CWP deployment scripts. Despite a couple of early deployments (to get an initial codebase onto UAT), we hit an issue whereby we were not able to deploy new code or roll back to a previous deployment despite having a backup. It was solved fairly quickly, requiring an upgrade of CWP module.
• Another deployment issue was directories weren’t getting exposed on CWP, also fixed fairly quickly by CWP.
• Any page containing an HTMLText field with an embedded YouTube video would return a 500 error. This was a major bug affecting every page using embedded youtube videos. Given that this was a critical issue we expected an urgent resolution however were informed it would probably be fixed in an upcoming release of CWP, over three weeks from when we discovered it. This cut very close to our deadline, but was fixed in the deployment.
• Global environment settings. The practicecentre required some global environment settings which we requested be copied across from the existing Silverstripe 3 instance, but failed to work on Silverstripe 4. This led to a large amount of discussion with CWP and tests on our end to try get it working over the course of a month. It was eventually discovered that the settings had been incorrectly applied by CWP. Once correctly applied it all worked as expected.

Feedback on CWP support:

• Support requests have no direct ability to mark as urgent without posting and then re-editing. This means that all requests get initially added with a default “non-urgent” status, and can therefore take several days or even weeks before being answered. Ability to set the priority could be part of the ticket submission process.
• There were times when the CWP helpdesk website was extremely slow to load. This seems to have been fixed recently however which is a marked improvement.
• The submission form also times out after 5 (?) minutes which on several occasions resulted in the complete form having to be filled in again due to a lost session (very frustrating when you have to start again, especially with technical responses).
• CWP/Silverstripe often seemed a bit too eager to close support tickets. Whilst some issues were also being tracked internally, closing these off means that the client has no overview of current standing issues or their current progress.
• CWP support desk obviously deals with multiple people for each project with different technical skills (project owners, developers, etc). I feel that several issues we had could potentially have been sped up had CWP been aware of that person’s role in the project, such as “this is one of the developers so we can get immediate technical feedback”.

Working on CWP and the Silverstripe CMS

As we do a large amount of work on Silverstripe, and are huge fans of it as a CMS, it was not a big change for us to work with the CWP platform.

We were initially under the impression that CWP would be far more restrictive than it actually turned out to be and we were pleased with the level of flexibility that we had to create a solution that meet the users’ and content editors’ needs. CWP provide a strong foundation, but it is really up to the developers to come up with the solution. There are some limitations, or rather procedures, that developers should be aware of, for example environment variables and cron jobs that can only be administered/set up by CWP staff.

The rule of thumb is to try use what CWP/Silverstripe provide (in terms of modules), and extend from there where necessary. One of the reasons for this is website audits - should the client require a website security audit then it is far easier for Silverstripe to evaluate the modules they are familiar with than others, and they do take the CWP platform into consideration when updating those modules.

Post-teething issues, deployments seem to work very well, and the system is reliable.

Silverstripe is extremely flexible, and CWP does not restrict this. Silverstripe are able to provide good technical support as they really know the product through and through, so it is great to have that fall-back if ever needed.