I've been looking for an easy way for my designer/themer to work on dev sites that are running under aegir, and I recently came across this comment by mig5 which explains that the modules, themes and libraries folders within a particular site are now writable by the aegir group. Part of my problem, of course, is setting up permissions correctly, so I thought that mig5's comment was going to solve my problem.

However, I immediately discovered another problem: we are using the development workflow found here, which means that all of my themes are in the profiles directory. That directory is not currently writable by the aegir group.

Could you make that directory writable by the aegir group also?

(I'm using the latest version of the omega8cc barracuda script to install and update aegir. I say that because I'm not quite sure if that means I'm running the latest version of aegir or not.)

Comments

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

I don't think this is a good idea. Hacking on code directly in /profiles will effect *every* site that's built on that profile. So, even one missed semi-colon in a theme could thus stall a whole team's work while it's being debugged.

Instead, why not just have the theme developer copy the theme folder from the /profile/[myprofile]/theme into /sites/[mysite]/theme? After clearing the theme cache, the local copy of the theme will override the one from the profile. Then it can be modified locally without impacting the rest of the team.

Once satisfied with the changes to the theme, the makefile can be updated to point to the new version of the theme, and a new platform built. Then migrate all the dev sites over to the new platform, and everyone inherits the theme changes.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Active » Closed (works as designed)

Furthermore, it is even not possible to allow write access for *any* SSH/FTP user in any Aegir instance created by Octopus, because by design all dirs/files in the drupal root (including install profile and everything inside) are owned by root, to avoid editing them by any non-root user.

You can use platform-wide sites/all and site specific sites/domain directories to override any module/theme located in profiles, but you should never touch directly those files.

Instead, the correct workflow (doesn't matter if using Barracuda/Octopus or not) is to create new platform with modified modules/themes in the profiles directory, but this location should never be touched/changed once the platform is deployed and used by sites.

ldweeks’s picture

ldweeks CreditAttribution: ldweeks commented

Makes sense, thanks.