Tag Archives: Elgg

Posted on
by

Elgg, like Idno supports a number of different views on data – standard HTML, JSON etc. However, unlike Idno, Elgg does not natively support JSONP.

JSONP allows you to make cross domain calls using JSON data, and is very handy for querying data from other sources using your fancy-pants javascript/jquery ajax code. It’s how, among other things, the idno feed widget running in the sidebar works.

Anyway, a commenter on another post asked about Elgg support, and because I had a few minutes spare, I put together a quick plugin!

» Visit the project on Github...

Posted on
by

Following from a similar post, where I packaged up my standard web services libraries to avoid repeating myself, I decided to do the same for Events and triggers.

Events provide a very powerful, flexible and simple way of providing hooks for other code to attach to, in a loosely coupled way. I’ve been using event driven development in my PHP code for years, way back since the first days of Elgg. In Elgg, events and triggers proved to be one of the frameworks most powerful, and a major factor in its success, allowing plugin developers to easily change core functionality without changing a line of core code.

Anyway, I’ve used Events in one form or another in pretty much every framework since, and I’ve found myself increasingly cutting and pasting code around, so I figured it’d be sensible to package this up into a reusable library as well. Although it is designed to be simple, the library is pretty powerful.

One particularly useful feature is that event listeners can include regexp!

Triggering an event…

If you were writing a framework that had users for example, and you wanted to allow plugin authors to hook in and do something when a new user is created, you might do something like this in your registration code…

function registerUser($username, $password) {

    ...
    // User creation code here
    ...

    // Ok, now tell everyone that a user has been created
    \simple_event_dispatcher\Events::trigger('user', 'create', ['user' => $new_user]);

}

Listening to an event…

So, if you wanted to listen to the user creation event inside your plugin…

// Register an event for every time a user is created
\simple_event_dispatcher\Events::register('user', 'create', function($namespace, $event, &$parameters) { 

    // Your code here

});

You can replace any part of the $namespace or $event string in Events::register (‘user‘ and ‘create‘ respectively in the example above) with regular expression. So, you could, for example, replace ‘user‘ with ‘*‘ to listen with any create event.

Code on GitHub, have fun!

» Visit the project on Github...

Posted on
by

elgg_logo1 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

  1. Install the source code for your project; scp it from the other site, git clone –recursive, whatever…
  2. 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

  3. Copy this file onto your new host.
  4. 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 `db_username`@`localhost` identified by 'db-password';
    use new_elgg_database;
    source /path/to/database-dump.sql

  5. 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!

  6. 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!

  7. 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 ~/public_html).
  • 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, RewriteBase /~marcus/elgg/

Files

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.

  1. Using rsync or similar copy the complete data directory from your old site’s data directory to the new.
  2. Ensure that the directory, subdirectories and files are read and writeable by your web server’s user.
  3. 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.

Happy hacking!