Dear Abdulaziz ,

Greetings!

I have worked on Elgg platform for one of my client in order to prepare a Twitter Dashboard & Profile page in Elgg from scratch and would be happy to assist you with plugin development work.

Please share your email address and Skype ID so that we can communicate better.

Hourly Rates(USD): $12/Hour

Hoping for your prompt response.

Warm Regards,
Norman
Skype ID: cis[dot]norman
Email ID: norman[dot]cis10@gmail[dot]com

Problem with using elgg-cli is that the shell user you are logged in as might not have the necessary permissions to read/write the files and folders (e.g. data directory of Elgg) that would have to be accessed during the upgrade.

To be honest, I haven't figured out myself how I would make use of elgg-cli without breaking things. With the normal user I also get permission denied issues. The webserver user (who owns for example the files in the data directory) is not allowed to execute any shell stuff and when doing stuff as root user there's no immediate problem with permissions (as root can read/write everywhere) but with any newly created files and folders you most likely get problems later when these files and folders are supposed to be accessed by the webserver who fails to do so if the files and folders are owned by root.

The upgrades can be run when logged in to your site from the admin area, too, after composer has upgraded the Elgg version. Maybe that's less troublesome.

It seems that this method does not work for Do you use the other manual way is by scanning the site files and add files of the new version, but this way will enable me to maintain the posts and evidence on the site?

Have you upgraded Elgg before or have you never tried it?

Have you installed Elgg with composer or had you installed it by using the zip archive available here on the site?

composer only deals with upgrading the content of the install folder of Elgg. By default it wouldn't deal with additional plugins and it's a certain knowledge necessary to handle it.

If you have not used composer so far, there's no need to use it now. The legacy way with using the zip archives of Elgg versions can still be used also for Elgg 3 (http://learn.elgg.org/en/stable/admin/upgrading.html#b-manual-upgrade-legacy-approach). Some might prefer using composer, but I would definitely suggest to learn how to use composer by trying it on a separate test installation and not on your production site.

The data of your Elgg site is in the database and in the data directory. Changing the content of the Elgg install folder (i.e. replacing the files with a new version) does not result in losing the data. Just read the upgrade instructions BEFORE trying to do the upgrade. And always BACKUP the install folder, database and data directory BEFORE starting an upgrade.

You don't have to compare every single file of the old and new Elgg version to find out which files to replace. When using composer the replacement of the files would be done by composer. But also when using the zip archive (legacy) method to upgrade to a new Elgg version you don't have to manually replace every single file. Backup first! You can just delete the old files of Elgg within the Elgg install folder with a few exceptions (keep .htaccess, keep elgg-config/settings.php and keep the plugin folders of 3rd party plugins in the mod directory and in case you have other files in the install folder not belonging to Elgg also keep these). All the other files can be deleted and then the new version of Elgg can be copied into the install folder. Then you need to upgrade elgg-config/settings.php and .htaccess (especially when upgrading from Elgg 2 to 3). The templates of these two files are vendor/elgg/elgg/install/config/htaccess.dist and /home/daniel/public_html/elgg20zip/vendor/elgg/elgg/elgg-config/settings.example.php. You would take these template files and edit them to add your site-specific data (in the settings file you would add for example the database credentials, in the htaccess file you might need to change something if you made changes in .htaccess on your own in your current Elgg installation). Then you would save the edited template files as .htaccess and elgg-config/settings.php respectively. The install folder would be updated now. The next step would be to upgrade the database as described in step 6 and 7 at http://learn.elgg.org/en/stable/admin/upgrading.html#b-manual-upgrade-legacy-approach.

If you upgrade from Elgg 2 to 3 you should only do so if there are compatible versions available of all 3rd party plugins you use. Otherwise, it's very likely that they won't work on Elgg 3. Best would be to try the whole upgrade process with a test installation if you have never done it before. While backups are a MUST and the site can be restored using the backups in case something unexpected happens or something simply goes wrong it is surely better to know before what exactly happens during an upgrade. And learning it on a test installation where no important user data is involved is surely a good way.

Or even version 1 to 3?

UP

The default theme of Elgg 3 has been quite thoroughly rewritten. It should cope better on varying screen resolutions (even if the de-facto default theme of Elgg 2, i.e. the Aalborg theme, was also a responsive theme). It should also be easier to customize the theme (or create a theme) on Elgg 3 as certain config options can be set via CSS variables.

It should also be easier to get a consistent look throughout the site on Elgg 3 also with 3rd party plugin of these plugins make use of the theming conventions offered by Elgg 3 core. Plugin developers should have less work to do to get their plugins look consistent. Though for existing plugins (for Elgg 2) the developers would not only have to make their plugins compatible with Elgg 3 but they might have to upgrade their code addionally to get rid of some plugin-specific code that was necessary on Elgg 2 to achieve a certain look but might no longer be necessary on Elgg 3.

Elgg 3 should be better maintainable (code of Elgg core and properly written/upgraded 3rd party plugins). But that's an advantage that will only show up in future (and probably more important for developers). On short term Elgg 3 has less plugins available as not quite a number of plugin have not yet been upgraded (including a number of my plugins - struggling to find the time working on them).

Elgg 3 uses another DB engine (InnoDB instead of MyISAM). The InnoDB engine should have a better performance because it doesn't require whole table locking but can deal with row locking only. Elgg 3 also supports the utf8mb4 encoding, i.e. better support of some languages and also support for emojis.

Caching options (like memcached or redis) might work slightly better. Though it might be less noticeable if you just make use of existing plugins while it might make a difference if you try to make use of it as a developer.

Elgg 3 is the future (with regards to long term support - years to come - even if Elgg 2.3 will still be supported for a while certainly). When to upgrade an existing site to Elgg 3 is most likely a matter of which 3rd party plugins you are using (or when starting a new site NOW you definitely need NOW). If the core functionality of Elgg 3 (and already available plugins) is sufficient, you can give it a try. If you rely on some plugins not yet available for Elgg 3, you can't upgrade just yet obviously. Or you might want to give Elgg 3 just a bit more time to get more stable - nevertheless you could test out Elgg 3 on your own for example in a local test installation to see for yourself the difference betwenn Elgg 2 and 3.