@Ron:

Possible helpful tips:

• in any case backup everything prior the upgrade (install dir, data dire, database),
• if using a maintenance plugin you could announce the planned upgrade to your users in advance. On Elgg 1.9 a maintenance mode will be included in Elgg core fortunately. For Elgg 1.8 I don't know if there's currently a full-working maintenance plugin available. Of course, you would have to test such a plugin prior a site-upgrade. And this plugin would have to stay enabled also during the upgrade.
• before starting with the upgrade / disabling 3rd party plugins (especially anti-spam plugins) you could disable account-registration in the advanced site settings. Then no new accounts / spam accounts should appear until the upgrade is finished.
• preparation of the "new" install directory in parallel: you could create a directory outside your doc root folder where you copy the new Elgg version plus all your 3rd party plugins plus .htaccess and enginge/settings.php. Once this directory contains all necessary files that need to be included in the Elgg install directory (and after making the site backup!) you can do the site upgrade by completely deleting the content of your Elgg install directory and then move the content of the prepared new install directory in place. The advantage of doing it this way is that you can prepare the new install folder without hurry while moving the directory content on the server will happen much faster compared to uploading/copying via ftp/ssh. Also, you won't have any outdated/deprecated files of the former Elgg versions remaining in your Elgg install directory afterwards.

There's no need to disable any plugins for a point release upgrade.

In addition to what was mentioned you can simply disable registration in the advanced settings during the process and turn it on again after if you are worried.

Hint: if you set your server up so that the elgg installation is a clone of the git repo, you can simply run

git fetch origin

git checkout tags/1.8.17

Then run upgrade.  The entire process will be done in under a minute.

@Matt: "git checkout" on a productive site!? Maybe I'm too "old-school". But it surely has the advantage of only changed files to be updated (faster) and files removed in the repo getting removed on the server, too. Still, I personally prefer to take a look into the content of the zip archive before blindly copying something on my server.

Another option is to

1. Announce the maintenance to the users.
2. break the db coneection by changing the connection parameters in the engine/settings.php file.
3. Upload all the files.
4. Re-enable the connection.
5. Run the upgrade.php

It's hardly 'blind copying' - the repo is public - you can inspect it at will before checking it out :)

@Matt. It's interesting that there is no need to disable any plugins for a point release upgrade. We always have, so it's interesting that we may not have to. On the other hand, because we use ismayil's hype framework (plugins) we don't upgrade until we have his blessing, we have found that to be a good and valuable practice. So, I'm not sure that the instruction is perfectly correct.

@iionly said "Also, you won't have any outdated/deprecated files of the former Elgg versions remaining in your Elgg install directory afterwards." That too is interesting. Over the past many years I always questioned this a number of times, and I was always instructed to a do a copy-over rather than a full replacement. Confusing what's best.

@all Thank you for the advice. Like I've said, we've done many upgrades since ver .9, but this is the first time we are under spam attack. Since we are not elgg devlopers much of what you all say is foreign to me, but I will try to deciper some of it to have a safe upgrade. The one that sounds like it may stop the attack during the upgrade is @Team Webgalli instruction to change the connection paramerter in the engine setting. php. I am assuming that the settings.php file is not written over during the uploading of the new files? Is this a correct assumption?

Thank you

@Ron: both settings.php and .htaccess are not overwritten when you copy a new Elgg version into your Elgg install directory as these files are not included in the zip file but only created when you run an Elgg installation. So, you won't lose your database settings in settings.php or any custom modifications in .htaccess. But you should check for differences between your settings.php and settings.example.php and .htaccess and htaccess_dist before running the upgrade script. If there are any differences apart from what you changed yourself (and of course the database credentials) you should merge these changes into setting.php and .htaccess respectively. It depends on what version your upgrade from if there are any changes or not.

The tip with changing the database parameters in settings.php is surely interesting. Never thought about that!

Regarding "simply copy over" vs. "removal of outdated files": you most likely won't not have any problems if there are outdated files but I prefer to get rid of any files no longer used. Then I can be sure that there are no problems.

@iionly: I understand and appreciate your knowledge. -ron

For those using a version below 1.8.14 should definitely upgrade. I noticed a patch has been introduced in this release where a user that is denied registration from a plugin like spam_login_filter will actually be deleted.

Otherwise the account will be created anyway. The user cannot login, but you still can have hundreds of fake accounts.

In case anyone would have any further advice, my sites are still being attacked. Getting anywhere from 1 to 3 attacks a minute that ALL are being blocked by Spam Filter; so I'm not getting any fake registrations on any of our sites; but the attacks keep coming. I don't get why these jerks keep doing this when there's no registrations and no advantage to them. I'd hate to think that all our elgg sites are doomed to these attacks forever. Thanks for any further advice you can shed on this.