Search

Designers look at Symphony differently than Developers in several ways. I prefer to work in Symphony from the Admin interface most of the time. I like the extension modularity, but with modularity comes complexity. Git seems like the most important tool to setup Symphony in a stable, repeatable, simple manner. Is there another way of doing this? This might be considered a parallel discussion to Git: managing code.... How are other designers working?

A long-term solution to emails drives my use of git, but I also didn't want to risk an outdated members extension either. My solution to emails was to use the integration branch 2.3.x of the EmailTemplateManager. I've attached an pastie.org/7280048 that I'll refer to during my overview. It's not complete, but I'd be happy to add more information.

Example Transition from 2.3.2RC2 to 2.3.2 (Starting Point) Twenty Extensions described here. EmailTemplateManager is already on the integration branch 2.3.x. This process doesn't affect the existing Tag.

Overview 1. Reset my existing core from the integration branch to the master branch and make sure all of the extensions match. 2. Checkout the members 1.3beta2 tag.

Reasoning Git commits can change regularly. A branch points to a particular commit. In my case I just wanted to revise my original commit to the core and keep the same branch. I fetch the available remote branches with 'git fetch origin'. Force it to a known state with 'git reset --hard origin/master'. Force an update to the core submodules 'git submodule update --init --recursive -f' with the '-f'. Then I use a script 'git-auto-submod.sh' to reestablish the existing list of extensions after the hard reset. Next I change to the 'extensions/members' directory and 'git fetch' the available tags and checkout and name the 1.3beta2 tag.

  1. git fetch origin
  2. git reset --hard origin/master
  3. git submodule update --init --recursive -f
  4. Copy 'git-auto-submod.sh' and 'extensions.csv' to the web root directory.
  5. sh git-auto-submod.sh extensions.csv
  6. cd extensions/members
  7. git fetch
  8. git checkout 1.3beta2
  9. git checkout -b 13beta2
  10. cd ../..
  11. chmod -R 777 manifest
  12. Go to 'http://rootwebdirectory/install' and press the install button.
  13. chmod -R 775 manifest
  14. rm install.php git-auto-submod.sh extensions.csv
  15. rm -rf install
  16. git commit -m "232 with extensions."

Conclusion I can pick out the core and the extensions and use the Compatibility Matrix and verifying the integration branches within github (a topic onto itself). Then I use git to force it to a particular SHA1. I can use this in a test server instance, than I can apply it to a production instance. All database changes are current. I could copy new or changed pages, events, etc. at that time.

A stable and repeatable implementation begins by configuration using the Compatibility Matrix. My designs require generating multiple emails from a single form update. My networking department limits my access to the production command line.

Is there an alternative to Email Template Manager for generating email (not that I want one)?

It seems like there's a big hole in the Compatibility Matrix for generating emails from the admin interface unless you're will to use the integration branch. I'm interested in how people address using the integration branch simply.

By the way Tower has a pretty good summary of git commands.

Extending the conversation with myself ... I see pseudo-code for the admin interface that could be used to upgrade with the click of a button. I'm not a developer, but I may have to try this. **Dependency Management **

  1. Store a ensemble page on github relating core versions to extensions.
  2. User clicks an upgrade button in the System -> Preferences
  3. System retrieves the page, compares the existing version, displays newer versions to user.
  4. User selects new desired core.
  5. System verifies all extensions are production ready.
  6. If extension is not production ready, dialog offers integration branch alternatives.
  7. User clicks OK and it runs something like the script above.

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