Search

Hi guys,

I've been using Symphony for a few months now on a number of my own projects and quite comfortable with it.

I recently started contract work at an agency who are planning on using Symphony for an upcoming redesign for one of their clients.

They use SVN for their version control and a shared DB for local development

The problem we're facing is say 1 developer adds a new section/ds/page etc, as I understand it this can sometimes create an xsl file, but also modify the database.

This will then throw up an error for the other developers as they have the shared DB info but the relevant xsl files have not been committed / updated yet.

I know a few of you work in agencies doing symphony development, is there a way around this? Do we need local dbs and some way to migrate this?

What's the most effective workflow to work as a team on Symphony?

Thanks,

Mark

The problem we're facing is say 1 developer adds a new section/ds/page etc, as I understand it this can sometimes create an xsl file, but also modify the database.

The below are things that happen when you perform different actions in Symphony:

  • When you create a section, several tables are created in the DB (one table for each field created) and a couple of tables are updated (section info, field references, etc.) No files are created with this action.
  • When you create a data source, a php script is created under /workspace/data-sources. No changes are performed in the DB.
  • When you create an event, a php script is created under /workspace/events/. No changes are performed in the DB.
  • When you create a page, an XSLT file is created under /workspace/pages/. A new row for page settings is added under the pages table in the DB.
  • When you create a XLST utility, a file is created under /workspace/utilities/. No changes are performed on the DB.

With regards to synchronisation issues with co-development, the long view of Symphony is to eventually move to storing system structures (sections, pages) via files, and to only keep pure content data in the DB. This way structures can be version controlled (Git, SVN) without relying on the DB.

In the short-term, different agencies employ different solutions. One solution is to look at using a DB synchroniser extension, something like the DB Sync or the CDI extension.

If you want to go low-fi/oldskool:

You can look at having a master instance of Symphony that every developer connects to when they need to do section and page work. Once performed, export the SQL with something like Dump DB and commit it to version control. All other developers then pull the update before continuing work. With this method, it's important that any developer that needs to update sections/pages that they do it on the master copy. All other development work can be done on the developer's local instance. The one caveat with this oldskool method is that you need to watch out for extensions that modify the DB, like the Global Resource Loader.

Hi Allen,

Thanks a lot for your reply, very useful! Your run through of how Symphony uses files/db will help a lot too.

So as I understand it, developers can go ahead and create as many Sections, Datasources and Events as they like, as the database is shared (for sections) and the Datasources, Events, Utility files need not be committed right away.

Its also unlikely that 2 developers will be working on the same page at the same time, our problem occurred when one developer had added a new Datasource to the home 'Page' which hadn't yet been committed, so there was an XSLT error for the second developer.

This is unlikely to occur often, especially when the foundation/structure of the website has been put in place.

I'd seen the DB Sync extension before but not CDI, so I'll definitely take a look at that.

Do you know if these extensions are able to export structure only and not content, for example, to not remove comments on a live website when the updated database is imported.

Thanks again,

Mark

Do you know if these extensions are able to export structure only and not content, for example, to not remove comments on a live website when the updated database is imported.

Yep, that's exactly what they do — they don't touch content, just section/field/page structure.

I'm still not sure if CDI or DB Sync will solve the problem — presently I think both of these save changes to a local .sql file, meaning you can't have multiple developers working on the same site at the same time. For this to be possible the changelog must be saved somewhere central (i.e. the database). I think Remie is updating CDI to do this, so might be a good idea to get in touch with him. CDI is superseding DB Sync anyway.

Yep, that's exactly what they do — they don't touch content, just section/field/page structure.

Hi Nick, thats awesome. This will be really helpful for my own freelance projects when I'm back to flying solo.

Based on Allen's run through in comment #2, I think we should be okay as long as two guys aren't both working on the same Page. Once all the fundamentals (header/footer datasources etc) are set up there shouldn't be a problem.. maybe!

I'll let you know anyway, as this is Day #1 of development so we'll see how things go.

I think Remie is updating CDI to do this, so might be a good idea to get in touch with him.

Yes, I'm definitely investigating this, but there is a small design problem that I still need to find a solution for: if you allow multiple developers to update the structure, how does CDI know the correct order of query execution. This can only be done if there is a central location where the CDI log is stored (so, instead of file, use a DB or shared storage). So this is still work in progress!

CDI is superseding DB Sync anyway.

It is the goal to achieve this one day, but I think mass adoption has to wait until the query delegates have been implemented and there is no need to hack the core anymore (IIRC Nils is waiting for this). This will be part of the 'upgrade to 2.3 effort' I hope to finalize this weekend!

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