Migrate to GitLab repositories
08 Nov 2015
Note: This guide is intended for Site Stacker developers that currently work on the repository cloned from ssrepository.com. If you have any issues leave a comment.
The Site Stacker repository was migrated to an on-premise installation of GitLab at https://git.sitestacker.com and will not accept any new push. Everyone that was working on that repository will need to clone Site Stacker from the new location.
Besides migrating to GitLab, the old Site Stacker repository was split into multiple repositories, as follows:
- a core repository at
sitestacker/sitestacker.gitthat includes everything Site Stacker, but without the repos below
- client components have their own repositories at
- all templates are in separate repositories at
- client themes have their own repositories at
Backup current folder
The easiest method is to rename your old directory and clone the new repository in place. This way you’ll keep safe any local changes that you haven’t pushed yet or untracked files, so you can come back to them.
On Windows, simply rename the old directory in Windows Explorer.
On OS X, use the
mv command, e.g.
mv ~/Sites/sitestacker ~/Sites/sitestacker-old-repo.
Before you can clone the new repositories, you’ll need a Site Stacker GitLab account. You should already have one.
If you can’t log in, try resetting your password first by entering the email you used with the old repository. If you get “Email not found”, contact email@example.com.
You can clone any Site Stacker GitLab repositories using two URLs:
Method #1 (through SSH) is recommended because it is faster and doesn’t require you to specify the USER and PASSWORD. To be able to use it you need to configure an SSH Key.
Clone Site Stacker core
Below you’ll find instructions for:
In PhpStorm, use Check out from Version Control as shown below:
Enter the repository URL and local path:
And you’ll be prompted for a login and password. These are the same as your GitLab account (either username or email will work):
After cloning, you’ll be prompted to open the directory. If you want to keep your previous settings you may chose No, and copy the
.idea/ directory from your old folder.
Using the terminal
# replace "~/Sites/sitestacker" with your own path git clone "https://git.sitestacker.com/sitestacker/sitestacker.git" ~/Sites/sitestacker cd ~/Sites/sitestacker
Configure the new installation
At this point you have Site Stacker core successfully cloned from GitLab.
Configure the git identity
It is VERY IMPORTANT to correctly configure the git identity before pushing any commits, to avoid your push being rejected.
emai.php files from your old folder into the new clone at
webroot/data/ directory from your old folder into the new clone. This folder is ignored in git so you need to manually copy it over.
Copy unversioned files
If you had unversioned files in your old project, you may copy them over.
Tip: Ignore unversioned files in
If you have unversioned files in
webroot/(e.g. user uploaded files) you can create a
webroot/.gitignorefile and exclude those files. This
.gitignorefile will be ignored by git, so you don’t have to worry about it.
Run After VCS Update
http://<your-ss-domain>/dev in the browser and run the Run After VCS Update action to set up the symlinks.
You should now be able to access the Site Stacker admin interface. See below for information about templates, client components and client themes.
Clone components, templates, themes
You’ll notice your new Site Stacker folder doesn’t include any templates, client components or client themes. You’ll need to clone these separately. You don’t need to clone them all at once, clone only what you need.
Below you can see the GitLab URL path and the corresponding local path within Site Stacker for any component, template and theme.
|Repo type||GitLab URL Path||Local Path|
You can get the url of any repository you want to clone in GitLab:
You can see all the available templates in the
templates/ group (right side).
You can see all the available components in the
components/ group (right side).
You can see all the available themes in the
themes/ group (right side). Notice the theme name includes the component and the theme, separated by a
- (dash), as in
Cloning subrepos from PhpStorm
If you use PhpStorm, you can clone these subrepos using the Check out from Version Control function:
If cloning a template, make sure you create the
templates folder, if doesn’t exist:
To clone the
Wmtek template, you would use something like this:
When prompted to open the directory, chose No.
Cloning subrepos from terminal
If you’re using the terminal, you can use
git clone with the appropriate URL and path, from the Site Stacker root:
# template (replace <CLONE-URL> and TEMPLATE, twice) git clone <CLONE-URL>templates/TEMPLATE.git packages/templates/TEMPLATE # component (replace <CLONE-URL> and TEMPLATE, twice) git clone <CLONE-URL>components/COMPONENT.git packages/components/COMPONENT # theme (replace <CLONE-URL>, COMPONENT and THEME, twice) git clone <CLONE-URL>themes/COMPONENT-THEME.git packages/themes/COMPONENT/THEME
Configure Git Identity
The repositories will reject any commit that has an unknown author (the user name and email needs to match the user in GitLab).
Assuming your user name in GitLab is Joe Doe and the email is firstname.lastname@example.org, you can configure the git user globally (recommended) or per repository.
Configure the git user globally
git config --global user.name "Joe Doe" git config --global user.email "email@example.com"
Configure the git user per repository
Note: If you didn’t configure your git user globally, you’ll need to do this for every Site Stacker repository you cloned (e.g. core, templates, components…).
# inside a repository git config user.name "Joe Doe" git config user.email "firstname.lastname@example.org"
system_repository.xml file that was required in every package is no longer needed and SHOULD NOT BE INCLUDED ANYMORE, even though System Repository warns about it.
Synchronous branch control in PhpStorm
When you first click on the branch popup menu (bottom right), you’ll see a notice about Synchronous branch control enabled:
This is usually not desirable so you should disable it by unchecking it here:
Fix permissions on OS X
The webserver needs to be able to write to some paths. On a development machine, you can set your webserver to run as your user, to avoid any issues related to permissions. DO THIS ONLY IF YOU UNDERSTAND THE IMPLICATIONS!
To change the user in Apache, you need to modify the
/etc/apache2/httpd.conf file. Open it in your editor of choice with
sudo and search for lines that look like this:
# # If you wish httpd to run as a different user or group, you must run # httpd as root initially and it will switch. # # User/Group: The name (or #number) of the user/group to run httpd as. # It is usually good practice to create a dedicated user and group for # running httpd, as with most system services. # User _www Group _www
Change them to match your user and group, for example:
User calin Group staff
To find your user and group, do a
ls -l in a random directory, e.g.:
$ ls -l total 16 drwxr-xr-x 18 calin staff 612 Nov 9 13:55 App -rw-r--r-- 1 calin staff 113 Nov 9 13:55 README.md
It’s recommended to delete the session files as well:
sudo rm -f /var/tmp/sess_*
sudo apachectl restart