Just a quick one, and primarily to help myself out, I put together a very quick and dirty Vagrant wrapper for Elgg development. I found myself repeating myself quite a bit when it comes to putting together build environments, and working with other people, so it made sense to put together a quick vagrant build to help out my team.
This project acts as a wrapper around whatever Elgg site you happen to be developing, and provides a stable install environment based on Ubuntu Xenial, mariadb and PHP 7.0.
I hope it’ll be useful to you!
» Visit the project on Github...
I’ve been doing a lot of development work recently for clients based on Known which involve, among other things, needing to do fairly involved things with data and ACLs.
Because of this, I was finding myself spending a lot of time trying to see what was actually written to entities by looking at the raw database. This was rather time consuming, and because of Known’s (very flexible but abstract) data model, was rather tricky.
So, I took advantage of Known’s console interface (which I fixed and extended in a recent pull request), to start putting together a collection of useful tools. To use, simply symlink to the appropriate directory from within you
Be aware that you will need the current latest version of Known core from Github.
» Visit the project on Github...
Here’s the scenario; you’re a developer and you’ve been asked to do some work on an existing Elgg site, or you’ve built an Elgg site with some complex plugin interdependencies that you need to copy on to a live site.
In both cases, this primarily involves copying the source code and Elgg database from one site to another, here’s how…
Source code and database
- Install the source code for your project; scp it from the other site, git clone –recursive, whatever…
- On the site you’re copying, take a dump of the database. You can look in your
engine/settings.php for the database username and password:
mysqldump -u your-db-user -p elgg_database > database-dump.sql
- Copy this file onto your new host.
- Create a new database and install the Elgg database into it, in the mysql client do the following:
create database new_elgg_database;
grant all on new_elgg_database.* to
localhost identified by 'db-password';
- You should now have a local copy of the elgg database installed, but in order for it to work you need to change a few paths. Firstly, alter your dataroot and site location details in your prefix_datalists table:
update elggdatalists set value="/path/to/elgg/" where name="path";
update elggdatalists set value="/path/to/dataroot/" where name="dataroot";
Don’t forget the trailing slash on the paths!
- Next, you need to update the site url in the site object stored in the prefix_sites_entity table. For the vast majority of people (who only have one site object) this will be straightforward, for others, you might have to use a slightly different query in order to get all sites working as expected.
update elggsites_entity set url="http://localhost/path/to/site/";
Again, don’t forget the trailing slash on the URL!
- Finally, alter your copy of
engine/settings.php to reflect your new database details.
When I view my site, all the CSS is broken!
This is almost certainly a mod-rewrite problem.
- Firstly, check that it’s installed and enabled, and that overrides are enabled for your site URL (common problem if installing into
- Next, make sure that your
RewriteBase is configured. If you’re installing into a subdirectory on a domain (e.g.
http://localhost/~marcus/elgg/) you’ll need to set the
RewriteBase in your .htaccess file accordingly, in the case of my example,
The above should get you up and running with a usable site for testing, however if you want to fully migrate a site, you’ll also need to copy the data directory across.
- Using rsync or similar copy the complete data directory from your old site’s data directory to the new.
- Ensure that the directory, subdirectories and files are read and writeable by your web server’s user.
- Flush the caches. This is important since Elgg caches the locations of template files and other data in the data directory, which obviously will cause issues if you copy a cache file from another location! If the admin panel has become unavailable at this point, deleting the
system_cache directory from dataroot by hand will often restore it.