As mentioned in the 1.5 announcement post, MoreGallery 1.5 has some under the hood changes. In this topic I want to share what changes we’ve made and why… in case you were wondering 
Alpacka as transport package
Alpacka is our library of common code that we introduced earlier this year. It basically holds all the standard code we use for context-specific settings, parsing chunks, path placeholders for uploads and things like that.
Previously Alpacka was included in MoreGallery through composer. So MG shipped with a version, ContentBlocks ships with one and SimpleCart ships with one too. This was working fine, until we ran into a conflict where SimpleCart ships with v0.2, while MoreGallery requires 0.3. As there can only be one version of Alpacka in memory at a time, the order in which extras are loaded by MODX seems to play a factor as to when this is or is not a problem.
In MoreGallery 1.5, Alpacka is instead installed as a separate transport package. After installing MoreGallery 1.5+, you’ll see Alpacka was also added to the packages grid automatically. The idea here is that there is only ever one transport package with the name “alpacka” installed, and that can be automatically kept up to date on the latest release. That way, so long as we maintain backwards compatibility, we can stop shipping different versions of Alpacka within different extras.
With MoreGallery 1.5 we’re testing the waters on how this works in the real world, but if that’s successful we’ll also update the other extras that use Alpacka in the same way.
An alternative approach could have been using the package dependencies introduced in MODX 2.4, however I’m not very happy with the UI for that yet, and it takes several steps to install the package that way. Now we’re using some open source code originally developed by Bezumkin that automatically installs the dependency.
Object Oriented Snippet
The reason we needed a newer version of Alpacka in the first place, is because the mgGetImages snippet is now a class. A base snippet class was added to Alpacka, and we extend that in MoreGallery to provide the requested functionality.
As the mgGetImages snippet was getting fairly complex, with different possible code paths (single image or collection view? cached or uncached? with or without wrapper template?), this object oriented approach makes it a lot more legible and maintainable for us in the future. It’s “surface level” implementation shouldn’t have changed.
One example where this rewrite helped immensely is adding support for listing images from different resources, a feature request dating back to 2013. Previously that feature was rather hard to add, however after the snippet was refactored it only took around 10 minutes.
Now using Imagine instead of phpThumb
MoreGallery does a fair bit of image manipulation, like creating the manager thumbnail and processing point-of-interest crops, so we’ve been using an internal copy of phpthumb. Phpthumb !== Phpthumb though, and the version we were using was rather old and limited.
In 1.5 we’ve replaced Phpthumb with Imagine. Imagine is an object oriented library for image manipulation, and contrary to our previous phpthumb version this will actually use imagick on the server if it’s available. As a result, thumbnailing should be quicker and take less server resources.
This also opens up a more direct path to supporting things like filters and watermarks, and imagine actually creates images from svg too. Using Imagine additionally fixed an old rounding issue with images of certain dimensions, where the generated image would be off by 1px.
Conclusion
You shouldn’t notice these changes much, but if you do they should make things better.
If you like this kind of post to shed a bit more light on what we do under the hood, be sure to leave a comment or 
the post, and maybe we’ll do it more often when we refactor stuff 