Well I understand that
Can you update it to work with version 3?

I've started to work on it on the weekend. As it's only for Elgg 1.x right now I have to update it for Elgg 2 first (well, that's my way of doing it anyway). Right now I'm testing it on Elgg 2. Next weekend (hopefully) I can work on updating it for Elgg 3 and then also Elgg 4.

iionlyI am really grateful to you and the elgg team
Thank you you are doing a great job

The likes action on the river applies to the 'entity' about which the river item was create.

So if a user has a new avatar that would be the user. If a new blog was created it would be the blog.

Since we decided it wasn't logical to have Likes enabled on users and groups there is no Like action on the river activity for these kinds of entities.

Also you (in the Elgg datamodel) can't like a river activity only the subject of the activity. So Liking a new avatar would be the same as Liking that that user joined a group. Therefor if you Liked the new avatar you'd also liked the group join. This isn't what a user would expect.

Hope this explains why it's not possible.

Because of the limitations of activity items they maybe should be upgrade to be entities. That allows liking them for instance. This idea has been mentioned earlier here: https://github.com/Elgg/Elgg/issues/10591

That issue/mention is 5 years old (not that early), what happened?

I know Elgg is a framework and we as developers need to create things with it, but I also think Elgg is more than just a social networking framework, at least could be more.

The majority of users of Elgg use it as it is, as a social networking platform not framework, that's why you guys created so many plugins and added so much features to core...maybe it's time to push even more features...just a friendly suggestion.

I'm just a web designer and soon to be a web developer, I really want to be able to help with this project, but will take time, like your time, which is most important, and not to mention working for free, but it's not impossible.

Thank you very much for building such and amazing platform!! I will dedicate my spare time learning more about php and Elgg to help you guys make Elgg even better. You probably heard these words before...but a scorpio keeps his word...mostly :))

Just felt the need to deviate a bit...sorry!

With this configuration, you're better off staying on Elgg 3.

Just update on the latest version.

If you want the most stability than use the LTS version of Elgg (currently 3.3) If you wish to use the newest features use the latest stable release (currently 4.0).

I know plugin support is important, that is up to the individual developer of a plugin which versions they wish to support.

We (ColdTrick, Jeroen Dalsem and me) only support the latest release of Elgg. The older versions of the plugins still work but bugs will only be solved for the latest release of Elgg.

Also have a look at the Elgg support policy to find out what works best for your use case. http://learn.elgg.org/en/stable/appendix/support.html

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');
       }

......

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

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

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.

Welcome back!

Look at our apps for inspiration: 1, 2, 3, 4, 5

Thanks. I have been spending a couple days doing everything I can the vanilla way and will chime in if I run into something new. A lot of the features that I added to 1.8 are part of 3.x.