Upgrading from 3.11 to 3.11.6

Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Number of replies: 29

Hello,

Although I see several errors similar to mine, I don't understand the solutions as they are all on other types of servers.

Before I go any further, I know a shared server is not ideal for a moodle installation; however, we have an extremely small enrollment and class offerings. Anyway, the issue relates to max_input_vars.

The help page states: "To change max_input_vars you can either set it in php.ini or modify it in runtime, for example for Apache you can create .htaccess file: php_value max_input_vars 5000 "

I tried adding this line to the .htaccess file in my public_html folder. Got a 500 error

I then changed the PHP version in Bluehosts MultiPHP Manager. Didn't work.

Now our installation is not working, and I'm at a loss here, so any help would be greatly appreciated.

Attachment Screen Shot 2022-04-09 at 12.33.06 PM.png
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

How was the 3.11 version installed to begin with?

Normally, think what one sees in an .htaccess file is placed there by the server's cPanel (or other panel) and there is normally a comment at the top that warns not to edit manually.

Is that comment there?   What else is in that .htaccess file?

When you change PHP versions, you can't go too high ... cannot use PHP version 8. And in that interface you have to change PHP versions, one also has to check PHP extensions that would be loaded with the PHP version chosen.

You might now need to create a phpinfo.php file and drop it in your code root (public_html) to see what's going on there.

Please see: https://www.bluehost.com/hosting/help/164

You also might use BH hosting help to see what else your hosting provider might have as a resource for your shared hosting package choice.  Granted you may not need much but you might be close to having to take your site to the highest shared hosting package offered by BH.

'SoS', Ken

Average of ratings: Useful (2)
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -

@Ken, Thank you for your prompt and detailed reply.
With your help, I fixed the issue by checking the PHP versions, and going into Bluehost's MultiPHP Manager.

As can be seen from the screenshot, our Moodle domain - which is the second item down the list - remained at version 7.3, whilst one of its subdomains inherited 8.0. I changed both to 7.3, and completed the Moodle upgrade.

Problem solved.

This disparity probably caused some sort of conflict - but I wouldn't know, honestly. Thoughts?

I'm also - thanks to your advice - going to create a phpinfo.php file just for the heck of it. I'd like to know what's mysteriously getting changed and whatnot.

Cheers! ~R

Attachment PHP.png
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

That's odd ... no 7.4?!!!!   PHP 7.3 has reached EOL ... and 7.4 is getting security fixes only from what I see @

https://www.php.net/supported-versions.php

While looking into BH researching your issue, ran across a page that said they were 'rolling out' PHP version 8.x in 2022 and that they would inform customers of the change.  Maybe you missed the notice?

.htaccess files are hierarchical ... top one in a 'domain' kinda rules the roost until another .htaccess file lower down/into changes things ... but just for that directory where contained.  IMHO, a terrible way to run a web server for a Moodle ... but what do I know! smile

Glad you got it fixed ... for now ... 4.0 of Moodle is on the horizon ... version is RC1 right now.   You might wanna go to Environment check and update the component, then set the drop down to '4.0 and beyond' to be forewarned of future Moodle updates/upgrades on shared hosting.

More thoughts ... recommend NOT doing 4.0 but wait until 4.1 as that is supposed to be the next 'Long Term Support' (LTS) for Moodle.

The strategy that I've found that works is to always attempt to 'future proof'! PHP/MySQL versions as high as possible/compatible ... along with LTS ... means less work and longer use.

Be prepared for an upgrade to your shared hosting situation as Moodle has never gone backwards in requirements ... only upwards/more.   You might inquire with BH now about your shared hosting package max's to know when to jump to whatever is next highest.

'SoS', Ken

Average of ratings: Useful (2)
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Thank you for the response. And duly noted.
One thing I've gotta clear up: Yes, indeed, they have the option for 7.4.
But! I went whole hog and updated to 8.0 just now, which didn't break anything, thankfully.
Now 8.1 is available, but I think I might wait for your response before I go ahead with that.
I hear you on 4.1. Best to wait, right? There are a few things like php extensions, etc:
The XMLRPC extension
php_extension to sodium
php_setting - opcache.enable
Buuuut I think these are okay leaving alone for now.
Thanks again!
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

It's your site and thus your calls!

http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases

PHP and DBMS compatibility of major Moodle releases
Footnote 4 and 5

https://docs.moodle.org/dev/Releases#General_release_calendar

Version support
Version     Release status     Initial release     General support ends     Security support ends
3.11     Current stable     17 May 2021     14 Nov 2022 (ext 6M)     13 Nov 2023 (ext 12M)
4.0     Future stable     April 2022     May 2023     November 2023
4.1 (LTS)     Future stable     November 2022     November 2023     November 2025

'SoS', Ken

Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
One other thing: I was told by BH that they can't change MySQL to full unicode support. I'm on utf8, and we need utf8mb4.
Remember, I'm on a shared server, but my other websites - on the same server have utf8mb4, so I don't see the big deal here.
How on earth do I export so I can change it myself?
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

Going forward with Moodle versions upwards, eventually, things that were allowed ... like utf8 ... become obsoleted and utf8mb4 with uff8mb4_unicode_ci become 'required'.

Note: I don't work for Moodle HQ nor a Moodle Partner - so am not privy to any truely known inside info.  Not capable of Vulcan Mind Melds either! smile

IF your site will have any courses for Asian languages OR you expect use of Emoj's with no issues, utf8mb4 will be required.

Again ... my take on things ... try to 'future proof' as much as one can without getting on 'leading edge/cutting edge'.   LTS info shared in previous response speaks for itself me thinks! smile

Converting DB yourself ... got command line (terminal access) via your cPanel?   If so there are some cli php scripts in code/admin/cli/ that will handle the DB stuff.  That would be the easiest/best option.   Could be one more reason to upgrade shared hosting package to the highest shared hosting package that had not only a "Terminal" icon but a "Git" icon.

Got phpmyadmin?   Suppose one could do same with that on existing DB ... just make sure you do all tables and columns in those tables ... that's where the CLI scripts make it darn simple! smile

If neither ... download an SQL dump of DB, then use a text editor to find 'character set utf8' ... change to 'character set utf8mb4' ... also search and replace for whatever collation is in the dump to uff8mb4_unicode_ci.

Then create a new moodle DB via cPanel interface and import your edited sql dump file using PHPMyAdmin.

Also change config.php db array for the collation to match.

Uhhh ... if you are going to attempt that, make sure you have a sql dump copy in case one messes that up! smile

'SoS', Ken

Average of ratings: Useful (2)
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
"Got phpmyadmin?"
It's more useful than milk, apparently. ;)
Lots of information here! I'll give that one a go.
I hear ya on the future-proofing. Best to cry now versus later.
Thanks again for your help. smile
Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Leon Stringer -
Picture of Core developers Picture of Particularly helpful Moodlers

Re the second option – download an SQL dump of DB, then use a text editor to find 'character set utf8' ... change to 'character set utf8mb4' – I don't think that will work if MySQL is using the old small index size because of the reasons outlined in this reply. In which case the import of the modified dump file will fail with errors like "Index column size too large".

The first step is to check the current settings with:

SHOW GLOBAL VARIABLES WHERE variable_name IN ('innodb_file_format', 'innodb_large_prefix', 'innodb_file_per_table');

you can run this in phpMyAdmin. For full UTF support these settings should be:

+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| innodb_file_format    | Barracuda | (Or blank)
| innodb_file_per_table | ON        |
| innodb_large_prefix   | ON        | (Or blank)
+-----------------------+-----------+

What do you get?

Average of ratings: Useful (2)
In reply to Leon Stringer

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

@Leon ... you correct ... only thing I was going on was

In https://moodle.org/mod/forum/discuss.php?d=433495#p1744185
OP did say:
".... but my other websites - on the same server have utf8mb4 ..."


Even if it failed on a new DB (no harm done), OP has more reason to move his hosting account package to something compatible.

And OP still hasn't answered how 3.11.0 was installed in the first place.
That version had the same environment requirements.
Softac/Other One Click Wonder install that managed to circumvent environment check or just ignored it?

'SoS', Ken

Average of ratings: Useful (1)
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Leon Stringer -
Picture of Core developers Picture of Particularly helpful Moodlers

It's possibly because those website's databases have no indexes on larger columns. MySQL/MariaDB's old index size was 767 bytes which would support up to VARCHAR(255) at utf8 (3 bytes per character) or VARCHAR(191) with utf8mb4 (4 bytes per character). So you can have utf8mb4 in a database without changes to settings but only if you don't have indexes on columns greater than this size.

The setting innodb_large_prefix = ON increases the index size allowing indexes on larger columns. Moodle uses this (for example there's an index on VARCHAR(255) column mdl_course.shortname) so to use the recommended full UTF-8 support (utf8mb4) then you must have the large index size.

But the innodb_large_prefix setting is removed from MySQL 8.0 and MariaDB 10.3.1, only the large index size is used. I'd recommend migrating away from a host that didn't support the settings recommended for Moodle.

(Slightly dated but I wrote this up once).

Average of ratings: Useful (3)
In reply to Leon Stringer

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Per your previous question, this database has full UTF support.
Ken had asked how I got to 3.11. Well, the short and simple answer is the Environment check didn't throw any errors during the previous install, so I went on my merry way. 🤷‍♂️
This time, however, I was stuck in a loop of sorts, and that's when I reached out to you fine people. smile
I see the instructions for converting to utf8mb4 here, but I'm not sure how to run the script in my configuration.

Attachment Screen Shot 2022-04-10 at 9.49.01 AM.png
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Leon Stringer -
Picture of Core developers Picture of Particularly helpful Moodlers

In that case I should apologise to Ken as both of his suggestions are correct.

Upgrading using the script requires command line (SSH) access to your hosting service, such as using PuTTY. You'd need to change to the folder containing Moodle then run the command. So if your Moodle source code folder was public_html you'd run the commands:

cd public_html
php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci

Using the script is the best way to do this. The download dump file, edit the text, then restore to a new database that Ken describes should hopefully work as an alternative.

Once you've completed either process you'll need to change the 'dbcollation' entry in config.php to 'utf8mb4_unicode_ci'.

Average of ratings: -
In reply to Leon Stringer

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

No need to apologize Leon ... you were correct!   Just that shared hosting setups are sooooo different from one another hard to determine many things!  Your query suggestion was right on target! smile

Now ... one more time ... on the initial install, did you use an app offered by BH to do the install?   The one normally seen in cPanel is called Softaculous.   If so, did it show Moodle's environment check or one of it's own?

https://docs.moodle.org/311/en/MySQL_full_unicode_support

Steps to upgrade - options
1. alter my.cnf - can't do that for that config file is for the entire server.

You are on shared db server as well.

2. Run the CLI script to convert to the new character set and collation

php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci

and

mysqlcheck -u root -p --auto-repair --optimize --all-databases

but you don't have terminal access and cPanel doesn't offer a tool to run a script.

3. If you only have access to the database command line (or something like phpMyaAdmin) you can try the following SQL commands:

Notice it says 'try'.  set global commands I thought were for entire server.
You don't have access to config of entire server, just your databases.

But the query you ran does show those are ok, doesn't it?

Still risky ... but looks to me like 2 options are open to you:
1. PHPMyAdmin
2. the backup, download sql, edit sql, search and replace, then create a new
DB and import edited sql into new DB.   Change config.php file as well.

Are we getting tired of having to 'work to work' yet?

If so, pursue upgrading the package you leased from BH.

If not, we (really me, can't speak for anyone else really) will eventually tire of 'having to work to work' ... and explaining how you *might* ... **** MIGHT **** be able to do that!

And if ... IF ... these things that *MIGHT* work fail and fails in such a fashion that
you loose it all, will you 'forgive' us?

As a former classroom teacher/coach who had first aid training, I re-call for sure 'do no harm'.   Same is true of providing advice for others in admin'ing their server/Moodle. smile

There comes a point where one has to go the path of least resistance ... if it means upgrading package to gain greater access and more control, do that.   Yes, that will cost more ... but ... here's a question for you to consider IF you charge for courses ... if your courses are worth it, that fee for just a few participants could make up the cost of the upgraded BH access.  Ever calculate your hourly rate in admin of your server? smile

'SoS', Ken

Average of ratings: Useful (1)
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
"Are we getting tired of having to 'work to work' yet?"

Well, you see, I call it "homework." And I am learning a lot. And - get this - I do have SSH access on a shared server, but there are a lot of new terms here, so it's going to require plenty of futher study on my part before I mess with the database.

I admit it is a lot of homework - that word again! - but I have no doubt I'll be able to accomplish these tasks under the circumstances.

To answer one of your several other questions: I installed Moodle myself, as I was told to stay away from Softaculous - convenient though it may be. I found it to be a very straightforward process.

Eventually we will migrate to a VPS or self-hosted server. For now, shared works fine. One of the perks of this setup is the abundance of well-written documentation. Proper grammar, spelling, and punctuation go a long way in helping someone like myself who is still learning.
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

Thanks for clarification!   So you don't suffer from 'clas' ... 'command line avoidance syndrome'.   That's good!  Sure wish that info was shared earlier!

Yes, learning command line is stretch, but, by far, the best way to admin a Moodle server - as Moodle documentation illustrates.

So here's a 'homework' assignment for ya ... login to your server via ssh and issue the following commands:

uname -an

php -v

php -m

mysql -V

whereis git

whereis nano

env |grep 'PATH='

cd public_html

pwd

ls -l config.php (if your code is in a 'moodle' directory: cd moodle then issue).

They all relate to admin of a Moodle! And none of them will do any harm ... although output of some above should be obscured if you share back here in forums! smile

'SoS', Ken

Average of ratings: Useful (1)
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Well! The plot thickens!
As noted previously, on the Environment check, I get the yellow alert saying I need unicode utf8mb4 - but get this: it's already collated that way when I view PHP My Admin.
See the screenshot. It's the first item on the list. The rest are utf8: Wordpress installations, and stuff like that. THAT'S probably what Environment is crowing over.
Oh, by the way, BH support verified that, yup, utf8mb4 is the default collation.
Guess I'll ignore the "Danger, Will Robinson" warnings from Environment check. ;)
Attachment Screen Shot 2022-04-10 at 3.49.27 PM.png
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

Don't let PHPMyadmin fool you ... a database can have different character sets and collations in tables and columns in those tables!

So ... we know you need utf8mb4_unicode_ci collation ... time to try something from command line:

cd /path/to/your/moodle/code/admin/cli/

Then issue: ls mysql*

The 3 scripts you see listed should be:

mysql_collation.php  mysql_compressed_rows.php  mysql_engine.php

Take a guess as to which  works on collation of the moodle DB, the tables in that DB, and the columns?

Issue:

php mysql_collation.php [ENTER]

That will bring up the help screen for that command.   Then re-issue with the help info you saw.

When I issue with -l option, this is what I see on one of my servers.  A summary!

Table collations summary for https://mysiteurl:
utf8mb4_unicode_ci: 1717

If there were other tables that had different collations summary would show how many and what those other collations were.

The help screen tells you exactly what to do! smile

'SoS', Ken


Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Ran the commands! Can't post the output here, as there is too much to obscure, as you say. ;)
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

The environment check in Moodle checks only the Moodle code/DB - the DB named in config.php of moodle code.   It will not check WordPresses!

Uhhh .... gave you a way out ... and you took it! :\

Most of those commands really don't need to be obscured!   But they are absolutely necessary for you to know if ... if ... you are going to attempt to follow moodle docs where you see command line.

Case in point ... uname -an will tell us what linux distro your shared server is running.  Makes a difference ... if server is a CentOS based Linux, you might not be using 'sudo' in front of all those commands.   And to install software, which you might be able to do, one won't be using apt-get!   Plus, and this could be a shocker ... you might be running a distro which is near EOL!!!!  So your future plans to build or lease might be sooner than you planned.

Another case in point - cron job.   That's setup outside of Moodle and does require you to know the path to php-cli.    php -v would have verified/shown that path to be valid.

It's also important to know that path is accurate to php-cli when executing the scripts in code/admin/cli/ to fix your database character set/collations issue.    Tried that yet?   Please do!!!!

php -m shows the php extensions installed.

What not to share ... maybe the url to your server, although that could be discovered via Google easily enough! (the 'blackhats' probably already know and have been poking and probing your WordPresse's for a long time!   BTW, a vulnerable WordPress can be the cause of a hacked Moodle!)   Obviously, any command that shows login/pass ... like a mysqldump command.

Sorry ... but the comment about 'if it ain't broke' ... even though this entire thread started with site being broken and we are just now discovering where and how bad ... that philosophy ... 'if it ain't broke' is one of the things that will lead to a site that is vulnerable and, sorry to say, eventually 'hacked' - and many times, the OP/Admin is blissfully unaware.   Goal of hackers/crackers now-a-days is not to disclose they have hacked your server.   They have gone beyond defacing the front page, but rather, will steal any user data you have or try to use your server as part of their bot network.

Ok, will get off my 'soap box' now!

'SoS', Ken

Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Very informative, Ken - and very much appreciated - yes, even your soap box proclamations! Keep 'em coming! smile
Yes, for me it's neither Alfred E. Newman nor the robot from Lost In Space. As with all things in life: it depends.
Our security is reasonably up to date. There have been no data dumps.
Still, at any time, anywhere, one of us could be the unlucky winner, right?
Now, I'm going to have a lot of fun with those CLI commands, however. Thanks again!
Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

"Proper grammar, spelling, and punctuation .."

First important lesson ... which you probably have discovered already, but just in case ... 'Proper ... punctuation ...' command line is an exception to that rule.   Linux is case senstive - Windows is not.

Did you notice the commands I've asked you to issue?   All are and begin with lower case but there are some 'options/switches' that are in caps.

And a hint about issuing moodlecode/admin/cli/ commands ... they must be issued from that location or operator has to provide the full path to those .php scripts to work.

In the 'spirit of sharing' (SoS), Ken

Average of ratings: Useful (1)
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

This ... "Eventually we will migrate to a VPS or self-hosted server" ... for future consideration/study etc.  2 things:

1. migration (moodle has docs on that)

2. VPS vs Self-hosted

The latter means you are going to purchase a server (the actual hardware), install an OS, then AMP stack - get Apache running and seen on port 80 and 443 with a valid fully qualified domain name and a valid certificate for https ... and that's even before you begin to attack the installation of moodle.   That last part of installing Moodle ... hint .. if you want easier admin install moodle with git.  Hardware ... how much memory?  how much space? how many CPU's? etc., etc.   Can give a basic thought ... better to have more than enough, than not enough! smile

A VPS - if you stay with Blue Hosting, more than likely, they will take your shared hosted account and stick it on a VPS .... which is good and bad ... all your stuff gets moved rather quickly, but ... but still in a user jail! (moodle still in /home/[accountlogin]/public_html/ .... which is not /var/www/html/  And if they also move your DB's to your VPS DB server, ask for the superuser credentials (login/password) to the DB server!!!!

 Anyhooo ... 'couch monster' is calling!   Have a restful evening! smile

'SoS', Ken


Average of ratings: -
In reply to Ricardo Silvestri

Re: Upgrading from 3.11 to 3.11.6

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers
Ricardo, I am not sure if it will help, but I made a few videos about installing and upgrading Moodle, at Ken's suggestion a while ago.

See https://moodle.org/mod/forum/discuss.php?d=401983#p1621924
Average of ratings: Useful (1)
In reply to Rick Jerz

Re: Upgrading from 3.11 to 3.11.6

by Ricardo Silvestri -
Thanks, Rick! Actually, I used some of the information on my initial installation. Eventually, yes, we'll migrate to VPS or self-host. But for now, if it ain't broke... ;)
Average of ratings: -
In reply to Rick Jerz

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

Well, this has opened another opportunity for me to make another suggestion!

@Rick ... have you ever tried using Git?   Do!

'SoS', Ken

Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.11 to 3.11.6

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers
Yes, Ken, I have, and it works. But I don't have a video showing this, yet.

@Ken,... in the past, updating plugins via git was a problem. Let's say you have a course with, oh, 10 plugins. When you use git, what happens to the plugins? Do they get updated? Do they crash? Does "git" take care of making sure that plugins are updated along with Moodle? What happens if you do not want a plugin upgraded?

I am not "anti-git." I am just wondering about plugins.  And I have my own case where I do not want the 3.11 version of one plugin, but rather the 3.10 version.  So I wouldn't want git out-guessing my needs.
Average of ratings: -
In reply to Rick Jerz

Re: Upgrading from 3.11 to 3.11.6

by Ken Task -
Picture of Particularly helpful Moodlers

Using git for core and plugins ... you already know the answer to those questions.  Git gets core ... not plugins .. unless you installed the plugin via git.   In that case, you would have to cd /path/to/plugin, git pull

The potential issue with plugin compatibility will exist with any direction one goes - git or non-git.   How do you know right now that a plugin doesn't have a compat version for 3.11.highest?  The environment check doesn't check plugins.   But one can run a looping bash shell script that uses moosh command to find out if a plugin has a version for destination core version or not.   But, just because they do, does that mean no issues?   Haven't we seen conflicts with plugins before?   Answer: yes!

Still, between the massive core vs 1 plugin, the largest part (core) done via git to me is a win.

Hmmmm ... changes to core happen also ... don't they ... you brought one up the other day.   Only way to avoid that one ... don't upgrade until the old behavior is to be supported ... but that hasn't happened yet ... and dare say it may never ... not enough votes!

Still, between git and other, I'll take git any day.

The real question is this ... which method saves you time and efforts?  Less time one spends upon updating /upgrading, the more time one has to teach.  Hmmmmm ...

Ok, have 'jabber walked' this thread now ... shame on me.   If we are to discuss this further, please post a new thread! smile

'SoS', Ken


Average of ratings: -