Stop the BC breaks?

After spending almost a decade doing themes and plugins for elgg, the time has come to take a hard decision. Elgg is dying because so many breaking changes from one version to another, it becomes harder and harder to maintain. For example, updating a 2.x theme is a pain. So many libraries being deprecated, and there isn't a proper guide on how to make a theme or upgrade an existing one. Just take a look at the "2.x to 3.x Upgrade Guide", it is a nightmare:

http://learn.elgg.org/en/stable/appendix/upgrade-notes/2.x-to-3.0.html

The elgg development team doesn't offer a way to migrate your code. Let's look at the elgg_load_library, there isn't an alternative for that. Even the elgg community is not willing to give a proper migration guide:

https://elgg.org/discussion/view/2937076/elgg-register-lib

As much as I want to upgrade my latest plugins and themes, the lack of proper development documentation has forced me to completely abandon elgg 3.x and focus on 2.x LTS version. Not only that, there are no new plugins being created, just the same users upgrading their old plugins. Elgg has stagnated and it is almost dead. I'm not against improving elgg, in fact I requested to use webpack instead of RequireJS (which is pretty much obsolete) or at least consider using inertia.js. Elgg is not even using a modern templating engine such as blade.

  • Hi rjcalifornia,

    thanks for letting us know how you feel. As a core developer i would like to respond to some of the things you say, to give some context to other readers.

    so many breaking changes from one version to another

    Elgg adhers to semver and only breaks features in major releases. This means we broke stuff in 3.0 and will also do so in 4.0. These major versions come out every 2 or 3 years. The releases also have a pre-release cycle in which other developers can help make transisitions easier by providing feedback. In between these major releases there should be no breaking changes. 

    The elgg development team doesn't offer a way to migrate your code

    We indeed do not help with a BC plugin or a script to update the code for you. You need to do that yourself. We provide documentation on what has changed in the code and what alternative features you can use to get the same results. Sometimes there is no alternative, hence it will break the code, but as stated before, those kind of changes only happen during major releases.

    has forced me to completely abandon elgg 3.x and focus on 2.x LTS version.

    This choice is all yours... if you have not had the time or energy to update your plugins to Elgg 3 in the last 2 years, you will also have a bad time updating them to Elgg 4. A big part of a software development is maintaining your code. Especially in webdevelopment.  

    Not only that, there are no new plugins being created, just the same users upgrading their old plugins.

    I believe this is mostly true. At least here on the Elgg community site this is the case. It probably also means that a lot of the custom work is already available.

    Elgg has stagnated and it is almost dead

    I can understand why you have this feeling. I have it too myself sometimes, however, things might surprise you. For example when we released Elgg 4 beta a few weeks ago it surprised me how quickly the translations on Transifex where update by some very active translators. This was not something i expected. 

    I'm not against improving elgg, in fact I requested to use webpack instead of RequireJS

    Wouldn't this be a breaking change? I thought you didn't want to break things... One of the reasons we did not do this, is that it would break all themes. Yes we need to move forward with theming and our JS framework, but that are changes for another major release.

    Like always: if you think Elgg should improve. Feel free to provide Pull Requests on github. It is an open source product and we are open to contributions.

    I would not like to see you leaving Elgg as you always were active here. If you do leave, i wish you good luck with your future endeavours. 

  • Hello. I agree on some points which @rjcalifornia mentioned but especially regarding the following not really:

    As much as I want to upgrade my latest plugins and themes, the lack of proper development documentation has forced me to completely abandon elgg 3.x and focus on 2.x LTS version.

    I have followed the documentation guidelines so I have upgraded many plugins from 2.x to 3.x. Of course it takes more time at the begging but then it goes quite smoothly.

     

  • I want to add a general opinion in this thread. Many times I get the impression that Elgg is developed only for "advanced" users and I think that's a BIG mistake. Reaching a "general" audience would be a qualitative leap for this framework and for this it is necessary to improve the update processes.

    I am an old programmer who stayed in the "html without css" :-) and I have Elgg installed with little knowledge of its interior. I tremble every time I need to update something. You should try to remove that "fear" from non-advanced users and Elgg will be much bigger. It's just my humble opinion.

    Regards, Wogker

    https://agujero.net/elgg

  • Wouldn't this be a breaking change? I thought you didn't want to break things...

    Breaking things that actually move forward elgg are good.

    Sorry I took so long to reply, I was working on this theme:

    https://elgg.org/plugins/3110405

    This theme uses Twig as a templating engine. It was quite a challenge because of how elgg works, and I don't even think this is the right way to do it.

    Like always: if you think Elgg should improve. Feel free to provide Pull Requests on github. It is an open source product and we are open to contributions.

     Using Twig was something I requested last year:

    https://github.com/Elgg/Elgg/issues/13242

    (Still no answers btw)

    One of the reasons we did not do this, is that it would break all themes. Yes we need to move forward with theming and our JS framework, but that are changes for another major release

    It is really surprising that OpenCart, Drupal, and even Yii uses Twig. Currently, elgg 4 is more of the same but complicating everything.

    I want to add a general opinion in this thread. Many times I get the impression that Elgg is developed only for "advanced" users and I think that's a BIG mistake.

    It is. Documentation is really bad. Just for example, what if you want to completely change the navigation menu? The view is very limited, and there's no documentation on how to do that. You have to dig into the code:

    $menu = elgg()->menus->getUnpreparedMenu('site', [  'sort_by' => 'name', ]);

    Or what if you use a templating engine and you want to display the user details? You can't just use this:

    $user = elgg_get_logged_in_user_entity();

    You will have to convert it to an object:

    $data['user'] = $user->toObject();

    I had to go through several forums until I got a solution.

    if you have not had the time or energy to update your plugins to Elgg 3 in the last 2 years, you will also have a bad time updating them to Elgg 4.

    I have no words.

     

  • I think BC breaks will always be annoying for existing plugins. You need to to make them working again without being able to add any new functionality with the time spend working on fixing the BC breaks only. I know the game since Elgg 1.8 when basically ALL the plugins I'm using were abandoned by their original developers and I could choose between giving up or trying to work on the plugins myself. Am I satisfied about maintaining 50+ plugins since then? Rather not unhappy maybe. I would definitely like the work shared between some more developers.

    Am I annoyed with the BC breaks itself? Not really. So far, the BC breaks seemed mostly justified. We had no responsive layout to begin with. Using Elgg on Mobile devices wasn't posible at all a few years ago. Fortunately, you can now. And the core developers face the same problem than plugin developers: fewer people available to do the job. So, some more BC breaks became necessary to simply make maintaining Elgg core easier! But why should the core developers spend time on making BC breaking changes if they surely could spend this time with nicer things? Apparently, the changes seem important enough to invest the time.

    As it seems unlikely that numerous new developers suddenly appear I can only suggest trying to maintain the support of plugins as you are happy with on your own. I stopped putting myself under pressure getting all my plugins working on Elgg 3 as fast as possible. If I'm in the mood, I still try to work on them. But now it seems Elgg 4 is out sooner than I can finish the work on Elgg 3. I thought that maybe some nice outlook could be that Elgg 4 requires less changes to get the plugins working again. But it might rather be different looking on the 3.x to 4.0 changes.

    Still, not all BC breaking changes are relevant for all plugins. And once you understood how the most typical changes are done the work goes much faster. If you are stuck with the docs of Elgg, maybe better ask sooner than trying to fix it on your own. @rjcalifornia As for the question how to deal with libraries I thought that I had answered it back then sufficiently. If you, just tell what you are stuck with and I can try to explain it differently.

  • As for the question how to deal with libraries I thought that I had answered it back then sufficiently. If you, just tell what you are stuck with and I can try to explain it differently.

    I tried upgrading one plugin to 3.x and I had several Fatal errors that I ended up just not upgrading plugins at all. The BC are not moving elgg forward, I mean no one is using RequireJS and here we are still using it.

    Yet, somehow removing these libraries is actually good?

    • elgg_load_library
    • activity_profile_menu
  • elgg_load_library

    elgg-plugin.php
    
    require_once(dirname(__FILE__) . '/lib/functions.php');
    
    Bootstrap.php
    
    use Elgg\Includer;
    use Elgg\PluginBootstrap;
    
    class Bootstrap extends PluginBootstrap {
    
           protected function getRoot() {
                return $this->plugin->getPath();
           }
    
           public function load() {
                Includer::requireFileOnce($this->getRoot() . '/autoloader.php');
                Includer::requireFileOnce($this->getRoot() . '/lib/functions.php');
           }
    
    ......
     

    activity_profile_menu

    Where did you get it?

    If it's a hook from /mod/groups:

    elgg_register_plugin_hook_handler('profile_menu', 'profile', 'activity_profile_menu');

    You can use from /mod/activity:

    elgg_register_plugin_hook_handler('register', 'menu:owner_block', '_elgg_activity_owner_block_menu');

    Or create own custom menu.

     

    RequireJS

    I don't understand what's wrong with it but you can look at this PR.

  • I don't understand what's wrong with it but you can look at this PR.

    Well, Webpack does literally everything that requirejs does, and so much better:     

    • Load in non-JS modules without a second thought as to weird pathing issues (styles/audio/images)    
    • Powerful compilation step for styles and scripts    
    • Supports hot-reloading styles without any additional work, and also has plugins for hot-reloading react components   
    • Super-quick compilation times, even on large projects, with sourcemap support    
    • Powerful module resolution options so you can lay out your project how you want without having to fight the filesystem
    • Very popular, with decent documentation and community support
    • Can load AMD/commonjs/UMD modules

    By the way, AMD is so overrated. We should be using WebPack, or worst case Browserify.

    Even WordPress has improved so much, without BC breaks. The new Gutenberg editor is modern, and still you can switch back to classic without any BC break.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.