OpenPSA News

OpenPSA 9.10.0 Released

webmaster@openpsa2.org (flack) — 2023-12-09T18:40:21+00:00

Go with the flow

A new release of OpenPSA is available. As always, it contains a large number of code cleanups, dependency updates, and general quality of life improvements. Notably, the datamanager library and the workflow UI has seen improvements for greater robustness and extensibility. Asgard and the RCS system also became more robust and versatile, and the framework continues it’s journey towards greater Symfony usage. To get all the details, feel free to peruse the changelog.

Enjoy!

OpenPSA 9.9.0 Released

webmaster@openpsa2.org (flack) — 2022-05-22T14:23:19+00:00

Divide and Conquer

The new OpenPSA release is continuing out long term trajectory of refactoring and moving to Symfony. Type safety continues to be improved, and more and more code is getting replaced by functionality from our dependency base.

A particular focus this time around has been on decoupling the various components from each other and from shared global state. This allows us to now offer individual components as separate Composer packages, which means slimmer, more performant installs. You can pick and choose from 30 components (which are continuously updated and have the same release tags as the main repo), and of course add your own!

Noteworthy functional improvements include support for cachebusting in asset loading, a greatly improved RCS frontend, and duplicate detection for groups. On the programming side, Datamanager’s subforms have seen many improvements in validation, UI and API, and a new color type.

The minimum supported PHP version is 7.3 for this release, and up to the latest 8.1. We switched from the deprecated doctrine/cache to symfony/cache, and also added support for solr 5.1+, PHPUnit 9, (most of) Symfony 6, and Monolog 2. Most JS dependencies have been updated to newer versions (elfinder, tinymce, fancytree, jQuery, fullcalendar).

Aside from that, there is the usual plethora of small optimizations, usability improvements, simplifications, and cleanups. We’ve also been contiuously increasing our test coverage and added more unittests. All told, the diffstat shows 1,352 changed files with 17,072 additions and 24,990 deletions.

Enjoy!

OpenPSA 9.8.0 Released

webmaster@openpsa2.org (flack) — 2020-12-31T17:06:51+00:00

Corona times are productive times

It has become a bit of a tradition by now: The year-end openpsa release, and 2020 is no exception. A lot has happened in the codebase since 9.7.0, and here are some of the highlights:

We have taken the next step in our great Symfony migration, and this one has been particularly big: MidCOM (the framework layer of OpenPSA) is now running on the full Symfony kernel, with the global getter being the entry point to the DI container. This means that all MidCOM services (RCS, caching, Internationalization and so on) are now injectable and can be configured using standard Symfony YAML files. A good chunk of the initialization work has been moved to the DI container’s compiler phase, which means less work has to be done on each request (and consequently, you need to empty MidCOM’s cache when you change the configuration).

Two concrete advancements that came from this is that the RCS service can now optionally run on a Git backend (which is more widespread by now than decades-old rcs). The logging service is now a wrapper around Monolog, which means that all of the latter’s features can now be used within the framework.

Datamanager also profits from the same improvements for configurability, and now provides better access to the underlying Symfony tools and sports better validation behavior. The dialog UI has received a number of updates, especially for better integration into JS workflows.

Of course, there has been the general modernization work, which brought support for Symfony 5, and the usual slew of JS component updates (elfinder, fancytree, tinymce, galleria, fullcalendar). At the same time we dropped support for PHP 7.0 which is well past its expiration date by now, and removed some old functionality that was only kept for 8.09 compat and reduced efficiency.

On the developer side of things, we now have better error reporting and much improved type safety, more unittests and unittest usability improvements, which should help speed up development down the line. There has also been some work on reduced coupling between the framework and application code, and between components in general. But more on that in a subsequent update.

OpenPSA now also sports somewhat improved responsive behavior, many UI & performance improvements as well as the usual fixes and cleanups.

Enjoy!

OpenPSA 9.7.0 Released

webmaster@openpsa2.org (flack) — 2019-12-22T10:51:12+00:00

It's that time of year again..

In this release, we finalized our transition to HTTPKernel, which now handles all request/response flows. This allowed us to make numerous improvements to asset handling, most importantly, assets can now be loaded "just in time": For example, the Javascript and CSS for UI messages will now only be loaded when there is actually a UI message to render. This means that the number of HTTP requests in a typical browsing session goes down quite a bit.

HTTP headers are now handled by Symfony, too, which gives us among other things better caching behavior. All in all, MidCOM responses are now smaller and faster, and since every ony of them passes through HTTP kernel, they can use all parts of the framework, which allowed us for example to improve the first run UX significantly.

The miminum supported PHP version is now 7.0, and jQuery has been bumped to 3.4.1. Also, the initialization logic for much of our frontend Javascript was modernized, so there is a lot less flickering when pages are rendered, which improves UX.

Aside from all that, there's the usual vast array of small performance & usability improvements, cleanups and simplifications. The diffstat shows 824 files changed, 7867 insertions, and 8366 deletions. To find out more, check the repo.

Enjoy!

OpenPSA 9.6.0 Released

webmaster@openpsa2.org (flack) — 2019-07-04T18:46:00+00:00

Now with extra Symfony goodness!

As usual during those last few releases, datamanager got a number of new features, for example better image handling. Also, the form is now locked later in the process, allowing for greater programmatic control, and templates now have more control over attributes.

On the framework side, the transistion to Symfony took a big step forward with the integration of HTTPKernel, which now handles (nearly) all requests, which unlocks a number of routing
features (like validation), and makes writing handlers a lot more user friendly. It also enabled us to remove a lot more superglobals, which improves testability, and allowed us to simplify the content cache and context logic, which now use much less memory.

Also, the component interface was simplified to produce a lot less boilerplate, which should make it easier to create new components.

Another focus was the removal of a number of longstanding UI annoyances, for example bad interactions between Bootstrap and our overlay UI, so UX should be a lot smoother now.

Starting with this release, midcom-console is now part of the main repo, since it is needed for almost all usecases anyways. This allowed us to also move the majority of midcom-exec scripts to the CLI, where there are nor execution time limits and debugging/monitoring output is
generally easier. Especially the Solr integration has seen numerous improvements as a result of this.

Aside from all that, the following items may be worth mentioning:

update JS dependencies (elFinder, fullCalendar, CodeMirror, etc)
enhanced ACL editor & Deleted Object handling in Asgard
the usual host of simplifications, cleanups, and performance improvements

The 1372 files changed, 23658 insertions, and 23759 deletions, so there's quite a bit to play with, if you install from Packagist, or directly from the source.

Enjoy!

OpenPSA 9.5.0 Released

webmaster@openpsa2.org (flack) — 2018-12-22T15:59:25+00:00

Just in time for the holiday season, here's a fresh release to play with

The most visible change in this release is probably that we have toned down our charming retro look by switching (almost) all icons from 16x16 PNGs to glyph icons, which is an improvement especially for high resolution displays.

Besides the integration of Symfony Routing already mentioned in the last article, the area that has seen most work is our new datamanager, which now supports a lot more of the old Datamanager2 functionality, and has become much more flexible towards future use cases. For example, you can now pass all regular Symfony Form options through schemas in addition to the classic DM2
ones. Also, you can now build form trees corresponding to an entire object graph.

The diffstat lists 1473 files changed, 22696 insertions and 26492 deletions, so you can image that there are many more improvements, for example:

improved offer creation & tracking workflow in Sales
updated JS dependencies (elFinder, fancyTree, jQgrid, tinyMCE)
the usual assortment of bug fixes, UX improvements, cleanups & refactorings

...and the rest you'll just have to find out about yourselves! OpenPSA 9.5.0 is available from Packagist, and of course straight from the source on Github.

Enjoy!

Routing, Symfonized

webmaster@openpsa2.org (flack) — 2018-07-18T13:54:14+00:00

YAML, here we come

As you probably know, a long-term goal of OpenPSA development is to reduce both the maintenance burden and the learning curve, by slowly replacing the framework's lowlevel infrastructure with Symfony components. Recently, we've made another big step in this direction by switching to Symfony Routing. This means that starting now, you can create your routes in YAML files in the regular Symfony format. This not only improves readbility, but also gives you access to a lot more validation and other features.

The second effect of this change is that now, URLs can be generated. So instead of hardcoding links, you simly call the router's generate() method, and it takes care of the rest. It might seem like a small thing, but you will appreciate it the next time you need to change URLs: Instead of searching the entire codebase with some fuzzy regexes, you simply update the routes file, and all the rest is taken care of by the framework.

Currently, Symfony Routing is available inside components (i.e. topic routing and midcom routes still use the traditional mechanism), and legacy component routing is still supported, so nothing changes immediately for existing code. However, the conversion from the old .inc format to .yml is really straightforward and can be done quite quickly, so don't expect the legacy support to stick around forever. Especially since there are a number of further improvements the new routing enables (which will probably require us to drop legacy support), but more on that in another post..

Enjoy!

OpenPSA 9.4.0 Released

webmaster@openpsa2.org (flack) — 2018-03-03T10:42:04+00:00

Forwards ever, backwards never!

As in the past, this release continues on the trajectory of refactoring and modernizations. Now that the last of our legacy dependencies have been removed, we could focus a bit more on the framework code itself. In this release, the old authentication system has been much simplified and will now use Symfony internally, as will parts of the i18n service.

We‘ve also bumped the PHP requirement to 5.5, since anything older is way past it‘s due date, and the newly available functionality has been put to good use already, for example to improve the code organization in preparation for the next round of the Symfony rollout.

updated JS dependencies (TinyMCE, elFinder, fancytree)
improved IDE autocompletion support for DBA properties
switch from memcache to memcached extension
improved support for more exotic DM2 configurations in datamanager
the usual vast array of small usability improvements, simplifications, performance improvements and bug fixes

OpenPSA 9.4.0 is available from Packagist, and of course straight from the source on Github.

Enjoy!

OpenPSA 9.3.0 Released

webmaster@openpsa2.org (flack) — 2017-10-11T14:07:36+00:00

It's that time again..

The next release of OpenPSA and the underlying MidCOM framework has arrived. The big news this time around is that we have switched over to the new, Symfony Forms-based datamanager. The immediate benefits are more, and more complete, localizations, HTML5 support, and a lot greater flexibility when rendering forms. And of course, this opens the door for many new exciting applications (not to mention that it gets rid of our last PHP4-era dependency..).

Aside from that, here's a few other highlights:

update bundled JS dependencies (elFinder, CodeMirror)
implement support for subtasks in project management & sales/invoicing
basic iCal create & edit support
more testcases and improved coverage
unbundling of optional components (DM2, tmp service, positioning)
Converted content cache & attachment serving to Symfony HTTP Foundation
many cleanups, API streamlining, small fixes and simplifications

As usual, you can get the release via Packagist/Composer, or directly from github.

Enjoy!

OpenPSA 9.2.0 Released

webmaster@openpsa2.org (flack) — 2017-06-18T16:32:49+00:00

Get it while it's hot!

As announced in the last release, OpenPSA 9.2.0 is the first version which drops support for the legacy Midgard PHP extensions. This allowed us not only to remove a lot of old code, but also means we can begin taking advantage of the greatly expanded functionality our Doctrine backend offers. This already lead to improvements in performance-critical functions, but more goodness is sure to follow.

Dropping Midgard support also allowed us to begin taking advantage of newer PHP functionality (although the minimum required version is still a very modest PHP 5.4), which helps especially in security-related areas, and also paves the way for the new (Symfony Form-based) Datamanager to be rolled out all over the tree. This will be the major focus of the next release, in 9.2.0, you will find among others the following changes:

updated bundled JS libraries (elFinder, tinyMCE, jqueryUI, fullCalendar, fancytree, jqGrid)
begin rolling out Doctrine-based performance improvements
PDF generation for offers
improved RCS UI & consistency in associated serializers
groundwork for resource support in o.o.calendar
many, many cleanups, streamlining, fixes & usability improvements

As usual, OpenPSA can be downloaded from Github or installed via Composer. If you encounter any issues or have questions, just let us know!

Enjoy!

A Viking Funeral

webmaster@openpsa2.org (flack) — 2016-12-18T20:09:21+00:00

All good things must come to an end. Especially if these things are software

Midgard has been a constant presence in OpenPSA ever since the days when Netscape ruled surpreme. In fact, it has been the foundation on which MidCOM was developed, providing a stable environment in a time when there were few native PHP frameworks that could have offered the same.

Unfortunately, the Midgard community‘s momentum never recovered from the introduction of Midgard 2. Similar to the KDE 3 to 4 migration of the same era, you had all the feature-complete and deployed code running on a framework in maintenance-only mode, while the newer, developing version was sufficiently different and untested that making the business case for a migration project proved to be very difficult. So Midgard 1 instances continued running on a stagnant platform with a builtin expiration date (due to the maximum supported PHP version being 5.3), while Midgard 2 never really took of, since there was very little code that could be made to run on it with reasonable effort.

At the same time, native PHP solutions for what Midgard provided became more and more competent, which only made the disadvantages of Midgard (limited hosting options due to the need to install custom libraries & a PHP extension, segmentation faults, more difficult debugging, little IDE support) all the more apparent, especially since it could never play out it cross-language strengths due to lack of adoption.

So the writing was on the wall (and in this blog) for a while now, and today, it has finally happened: Support for running OpenPSA on the Midgard extensions has been removed. It has been a good ride, but now it‘s time to say goodbye and send our old Viking friend on his final journey.

Right now, the removal of extension support brings us some welcome reductions in complexity and mostly unused code. Going forward, it will allow us to streamline our dependencies, the installation/setup experience and of course pave the way for many performance improvements by more fully utilizing the newly-available of Doctrine functionality. If you still have old sites you want to port to OpenPSA while continuing to use Midgard, you can use the recent 9.1.0 release, for new sites, enjoy the benefits of midgard-portable!

OpenPSA 9.1.0 Released

webmaster@openpsa2.org (flack) — 2016-12-16T22:04:32+00:00

Our second stable release has arrived

As announced during the last release, in this cycle, a lot of work went into removing unused and deprecated functionality, and bringing the code closer in line with modern standards. That is not to say that all changes were under the hood, there's a nice list of user-visible improvements, too, for example:

org.openpsa.notifier can now be extended with custom backends (like Slack/HipChat integration for example)
a new & improved Markdown editor replacing the unmaintained markitup! editor
UI streamlining & usability improvements all over the place, most prominently in the product database
Improvements in security-related areas like random string generation and login session handling
a new caching backend based on Doctrine Cache
new hcard parser (mf2)
Support for TinyMCE image editor, i.e. you can now edit images onsite

This is also the very last release that will still run on the Midgard PHP extensions. The test harness for these extensions has already been disabled, but the support code is still in place. That means you can still run openpsa-based sites on the extension. midgard-portable is now installed by default and will be the ORM of choice going forward. But more on that in another post.

Enjoy!

OpenPSA 9.0.0 Released

webmaster@openpsa2.org (flack) — 2016-07-02T16:07:41+00:00

Today, the 9.0 line was branched from master, and the first stable release, OpenPSA 9.0.0 was tagged, concluding a development cycle that started almost six years ago.

In over 5000 commits, the entire codebase was thoroughly debugged, refactored, streamlined, and modernized to work better in a larger number of environments: 9.0 can run on Midgard 1 (8.09.9), Midgard2, and Doctrine (via midgard-portable) and all PHP versions from 5.3 to 7.0 on Linux and macOS, giving you a wide range of development and deployment options.

You can read more about the details of the development progress in the preceding posts on this page. For now, suffice it to say that practically the entire frontend, all external dependencies and large parts of the business logic have been overhauled and improved, while retaining the maximum backward compatibility possible, in order to facilitate porting of existing sites and applications.

If you have been following OpenPSA‘s development, you may have noticed that we were production-ready and on a rolling release cycle of sorts already two years ago, so in terms of real-world impact, the big 9.0 won‘t be such a big deal. Still, it‘s always good to have something marked as stable, if only to better work with package management systems.

Going forward, the bigger deal with this release is that now that 9.0 is separated from master, we can start on the next rounds of improvements while still providing a stable dependency for existing deployments. Among other things, a new datamanager library (based on Symfony Forms) is incoming, as well as many performance improvements, once we switch to Doctrine exclusively. But more on that later.

For now, enjoy OpenPSA 9.0!

Taking the CUD out of CRUD

webmaster@openpsa2.org (flack) — 2016-03-01T21:21:20+00:00

a.k.a. New Editing Interface Inbound

While there has been talk about releasing 9.0 stable a while ago, something just didn't feel right yet, namely the state our administration interface. With most of the internals cleaned up now, and component functionality improved in a lot of places, most of the system is in pretty good shape, which made the shortcomings of the current editing metaphor all the more obvious.

There are a few different basic approaches that CMSs take with their editing tools, the most common one being a backend of some sort that is completely isolated from the user visible parts. This has the advantage that there can be no interference from frontend code, and the interface can be optimized properly for the task at hand.

For a while now this approach has been criticized for not being user friendly in the sense that what a user does is too far removed from the results of their actions, so in-page editing systems became the hot new thing. MidCOM was in fact an early pioneer in that approach, Datamanager2 includes inline editing functionality since time immemorial. However, it never really took of, because this approach created a number of problems on its own, for example interference of site CSS/JS with editor functionality, the problem of editing invisible fields, and so on and so forth.

For a while, we've tried to overcome these issues by switching to Create.js, which managed to address these concerns to some extent, and was generally a much more capable tool. But it, too, simply was not able to fulfill OpenPSA's needs. It's development seems to have stalled lately, so there doesn't seem to be much chance to see it improving in the forseeable future.

So in the end, we stuck with the status quo that has been around since the release of MidCOM 2.0. It can probably best be described as „inline editing without inline editing“, that is to say, there is no admin backend, all editing is done in the website itself, only there are no actual inline editing tools, instead a new page with a (backend) form opens in the frontend layout. So you had the problem of site/application layout bleeding into the admin functionality, while still being unable to see the effect of your edits immediately. For site/application developers it also meant having to allot time to the task of adapting/testing the admin interface with each new project they built, which is not exactly an incentive to use MidCOM if you don't have to.

So for the last year, we have been experimenting with different options on how to solve this dilemma, and it turns out that the solution is pretty simple: We're splitting the established CRUD (create/read/update/delete) cluster into one interface for Reading (i.e. the regular frontend of the site/app), and move the other three into overlays (iframes, if you want to get technical). This solves the problem of the admin interface interfering the site/application functionality, and at the same time provides a much more direct connection to the frontend than a dedicated admin backend could. The limitations of actual inline don't apply, since the admin UI is isolated, and the users can see the result of their actions as soon as they click save, with no further interaction required.

We've used this in a couple of production sites already and had quite encouraging feedback so far. Currently, the migration of mainline components is ongoing, and should be completed in a matter of weeks. Afterwards, the long-elusive 9.0 release should just be one stabilization period away.

You can play around with the current state on our demo server, or you check out the latest version directly from Github. In any case, if you find any bugs or have requests for improvements, just let us know.

Enjoy!

OpenPSA 9.0 RC3 Released

webmaster@openpsa2.org (flack) — 2014-11-26T21:50:28+00:00

Next stop: 9.0 stable!

As we prepare for going stable (there are no further RCs planned), the main focus of this release has been add robustness and streamlining of both the codebase and the user experience. We have also made a number of improvements to the developer experience it the form of improved IDE autocompletion support.

Other notable changes include:

better file picker integration for TinyMCE, including a new link picker
improvements to toolbar behaviour & flexibility
simplified (and faster) deletion workflow for most OpenPSA components
numerous fixes & improvements to reporting, sales, and direct marketing components
updated to new major releases of jquery.ui, fancytree and fullcalendar
the usual mix of cleanups, usability, and documentation improvements

In total, the diffstat shows 1594 changed files, with 9959 insertions and 16372 deletions. See the list of commits to get a full picture.

Over the Hill

webmaster@openpsa2.org (flack) — 2014-09-04T22:08:28+00:00

Heads up, everyone! 9.0 is almost upon us

After almost four years of incessant development, we're finally at a point where we can start a stable branch. "Stable" being a relative term, of course, seeing how during this entire time, the codebase has powered a number of production websites. What has changed is that, thanks to midgard-portable, we've shed our last unmaintained dependency, so we can expect to run sites on a stable set of APIs for the forseeable future. This means we can provide a point of reference for porting old Ragnaroek sites, and at the same time, we're free to make some larger changes to the master branch without having to worry about backwards compatibility too much.

What exactly will be done next is yet unclear, but there is a large laundry list of topics that need adressing. Here's a few of them, in no particular order:

Replacing HTML_Quickform with the Symfony Form and Validator components, which should give us much greater flexibility with regards to form handling
Making use of all the new APIs Doctrine provide. This should improve performance for data-heavy views considerably
Better CMS interfaces: Some preliminary work on this has already been done (e.g. Create.js integration, AJAX editing & toolbar cleanups), but a lot more is still to come
Porting to Symfony's HTTP Foundation, and eventually HTTP kernel

As you can see, the future won't get boring. But if it gets too exciting, there'll always be 9.0.x to fall back on.

OpenPSA 9.0 RC2 Released

webmaster@openpsa2.org (flack) — 2014-07-01T09:05:50+00:00

The main focus of this release is the addition of support for midgard-portable. You can now run OpenPSA and the framework with Doctrine ORM, eliminating the need to install a custom PHP extension.

Other notable changes include:

CSRF support in Datamanager2 forms
Replaced of the remaining PEAR dependencies (Text_Diff, HTTP_Request2) with Composer-based ones (php-diff, Buzz)
Port session handling and UI messages service to Symfony HTTP Foundation
Updated JS dependencies (including new major releases of TinyMCE, CodeMirror, and fullCalendar)
the usual mix of cleanups, simplifications and usability improvements

In total, the diffstat shows 3856 changed files, with 92404 insertions and 109190 deletions. See the list of commits to get a full picture.

OpenPSA 9.0 RC1 Released

webmaster@openpsa2.org (flack) — 2013-12-29T22:04:02+00:00

This release contains mostly small, incremental changes, and continued efforts to streamline the code base by removing unmaintained and/or not commonly needed functionality from the main repository. Where appropriate, the features are available through the midcom-extras package.

Among the most notable changes are

new, fullCalendar-based interface for calendar browsing
rewritten Watcher service, based on Symfony Event Dispatcher
numerous performance improvements in for working with large object trees in Asgard
improved PHP 5.5 compatibility
initial support for running on midgard-portable, and improvements for CLI mode and Asgard shell functionality
replaced unmaintained PEAR diff library with a Composer-based solution, and the PEAR Mail packages with Swiftmailer
the usual pile of refactorings, cleanups and usability improvements

In total, the diffstat shows 949 changed files, with 16064 insertions and 11024 deletions. See the list of commits to get a full picture.

Going Native

webmaster@openpsa2.org (flack) — 2013-11-10T15:48:32+00:00

A small update on midgard-portable

The midgard-portable repository on Github is now a little over a month old, and has been growing quite rapidly. Much of the added code consists of unit tests, but of course, the API emulation also added quite a few lines. The good part is that we are quickly reaching a point where all Midgard functionality used in openpsa is more or less covered. The test suite does not yet pass completely, but the number of failures is already quite minimal (8 out of 658).

This means midgard-portable is reaching the state where it can run actual application instances, and here's the screenshot to prove it:

As you might notice, this page not only says „midgard-portable DEV“ in the version field, it is also served by Apache on localhost using Mac OS X 10.8, which is most probably a first in the newer history of Midgard as well.

The whole experience is not yet completely bug-free, of course, but the vast majority of handlers functions as expected already, and Asgard is completely usable:

There are still a number of unit tests to write, and corner cases to consider, but overall, the adapter is progressing quite well, so a first alpha release can likely be tagged pretty soon. Of course, you don't have to wait for it, you can get the code from the repo directly and test it in your setup.

Enjoy!

The Big One

webmaster@openpsa2.org (flack) — 2013-10-19T21:54:11+00:00

All the roads lead to this

If you have been following the updates on the openpsa/midcom development posted here, you will have noticed that between all the refactoring, an important goal of development has always been to make the software more accessible to the rest of the PHP world. In fact, more often than not, this is what triggered many of the larger restructurings in the first place.

The first step on this road has been adding support for Midgard 2, which enabled us to run on PHP 5.4 and beyond as well as on different database types. PHP 5.4 support also meant significant changes to openpsa's dependencies, many of which had still been from the PEAR era (and a few of them still are). The move to Composer/Packagist-based distribution has been quite helpful in that regard, since it provided access to a plentiful source of current libraries. It also provided the basis for the new installation system, and has made openpsa more readily available to others who might want to integrate it into their projects.

So all in all, openpsa has been slowly moving into the bigger PHP world. But while these were all helpful and necessary steps towards better portability, one rather severe constraint remained untouched: The need to install a custom PHP extension and its associated libraries.

This may not be much of a problem for development, but restricts the choice of hosting options considerably. Basically, all non-Linux and most off-the-shelf managed hosting solutions are out of the question, and running multiple Midgard instances on the same server has always been somewhat problematic, so that only leaves you with running self-administrated individual VMs. And any project that wants to use parts of openpsa will limit itself to the same reach, which is not really much of a selling proposition.

The problem of course is that Midgard is not merely some dependency that could be switched, but rather the foundation on which the entire midcom framework and in turn openpsa are built. So for this not to turn into a multi-year, ground-up refactoring effort, any potential replacement would have to provide the exactly same behavior and API, essentially a Midgard without Midgard.

It took a while to figure it out, but it looks as though this Zen-like construct might actually be achievable, especially since the framework is in a transitory state as well: As mentioned above, currently both Midgard 1 and 2 are supported, so at the moment, we're restricted to the rather basic set of ORM features available in both incarnations. Which means that the requirements an alternative ORM must meet will never be lower than they are right now.

The most obvious candidate for such an ORM is Doctrine of course, but the fact that Doctrine uses very different paradigms than Midgard has long made this seem like an impossibility. Until recently, that is, when inspiration struck, and work on an adapter finally started showing some very promising results. It turns out that the baseline API required is still quite a handful, but some important checkboxes have already been ticked, so at this point, it looks as though a reasonably complete adapter could be written in a reasonable timeframe.

What's more, read access to Midgard databases already works quite well, so once the adapter can run in parallel to the Midgard extension, it could already be gradually introduced into existing applications to provide more expressive select APIs for performance-sensitive areas, without breaking Midgard 1 support.

Where this all leads remains to be seen, but the next important milestone will be to get openpsa's test suite to run, which might still take quite some time as there is a lot of ground to cover. Then, running actual application instances will be another big task. Assuming we actually reach the point where the Doctrine adapter (currently called midgard-portable) can act as a drop-in replacement for Midgard 1, an interesting choice will present itself: To either use Midgard 2's API or Doctrine's to further advance the project. Today, there is no way to tell which way that decision might go, but the point is: We will have a choice, and the means to provide better interoperability either way.