Hi there,
3 times i try to install the last Moodle version on web seb-domain site in 1and1 server - Linux.
I make all steps from the instalation guide. Download a zip file. Upload the file in a " ***.******.com/ " directory. This is root sub domain directory. Then unzip the file. Copy all files from /moodle directory to the root directory. Install Moodle from web. Make a database... all is ok, but when come the windows with master admin screen, there are no please to write a password...
And after that - nothing!
Please help me.
How did you make your database? And how did you create your moodledata folder?
I put here 2 picture from the 4 problems in installation screen.
* * *
And in the end...
The moodledata folder is maded exactly from the install instructions.
Can you turn on xmlrpc and fix the unicode problem?
Others here on moodle.org might have additional suggestions.
I try toinstall 3.6 version - The same problem!
Svar: Re: Svar: Re: Installation problem in 3.7.2+
Isn't it better to just install xmlrpc?
Hi all
I have the same problems I've spent few hours tying to get those errors out but with no luck, I even uninstalled/reinstalled MySQL and php followed all instructions on fixing SQL code-page problem bur the script to fis will not run due to infamous Options variable error from setupdll.php so even though MySQQL is set up for right code page restored data is not and provided means to correct it not working, for the slash arguments it is similar story seems that the documentation is working that well for that either. and still unable to complete installation.
I some how got 3.0.9 to upgrade to 3.3.9 despite the warnings, now stranded to go to latest since in the download it seems that the plugin WEBSERVICE_REST is missing.
Is there a way to get the WEBSERVICE_REST plugin and add through cli, since I'm in quite in an jam here since I updated php to 7.3.11 an the 3.3.9 version does not run on php 7.3 is there an different version that can be complete with all needed plugins?
This is getting awfully embarrasing.
Regards Stefan
Hi Rick
Come to think of it, I will probably never know, but when all dependencies are met and all basic requirements are met, I do assume it is compatible I'm also upgrading from 3.1 that has run on the server for years so it at least that has been compatible.
How ever I have got all check errors our except for ,,Allow slashpath" which seems to be impossible to get rid of.
I ended up upgrading to 3.6.9 stable and that seems to be working.
Thank's
Stefan
Do you host with 1&1 as the original poster in this thread?
If you downloaded 3.7.x code and then turned around and uploaded the code via FTP or some file manager did all files/folders were actually uploaded?
Reason I say that ... no, there is no CLI or other means to install webservices rest other than what comes with core code.
Download a 3.7.x zip. Unzip it. Look in moodlecode/webservices/ folder. There is a 'rest' folder.
Is that folder present on the server?
If not, use FTP or cPanel ... whatever you have to manage files ... and upload the 'rest' folder to your moodlecode/webservices/ folder.
Make sure ownerships and permissions are the same as you see for other folders and files in your moodlecode.
See if webservices/rest doesn't show now.
'SoS', Ken
No I'm not using 1&1, but an dedicated virtual machine, Ubuntu 16.14 LTS MySQL 5.7.27, PhP 7.3
The rest folder was not there an not in the .tar file either, but we settled on the previous Version 3.6.9+ that worked.
Thanks
Stefan
Lesson one ... don't piggy back.
Suggest, next time you have a probem, to begin your own forum posting so your issue gets the attention it deserves! ;)
So you downgraded or restored a backup to go back to a 3.6.x. Uhhhh .... is there a webservices/rest directory in that version. I run both a 3.6.highest and a 3.7.highest ... both have webservices/rest.
And you say you downloaded the .tgz file for a 3.7.highest and webservice/rest directory was *not* in there? Uhhhh ... well, that's funny ... I just downloaded the 3.7.tgz file and there is a rest directory!!!!
Soooooo ?????
'SoS', Ken
Assuming that a responder in this thread ((Kristoffer Schill) also host with 1&1, and solved the issues with command line install, have you thought about using the install.php script in moodlecode/admin/cli/ via ssh?
That script will ask for the same things as web based install but **doesn't have** the fancy protections for the password for the admin user. Can enter in clear text. For installing, the few minutes it takes to do that is ok security wise.
Comments: this entire thread might be a classic example of why it's NOT a good idea to 'piggyback' ... only time it's ok, is where one truly is working in the same environment.
And, 1&1 hosting (depending upon server selected when setting up a moodle - they recommend their 's server' ... which is smallest ... cheapest) is capable of hosting moodle 3.7.x
Qualification of this response: I don't host with 1&1. Do know that users pick their own poison when choosing a hosting provider and then must learn hosting providers way of doing things ... which isn't always like GoDaddy or other.
References from ionos pages:
https://www.ionos.com/cloud/cloud-apps/moodle
These applications run on Linux CentOS 7.
Minimum requirements: Cloud Server S
Tip!
Your contract allows you to use as many free apps as you’d like. Each app simply needs its own VM.
If 1and1, they do have documents for customers on PHP.
'SoS', Ken
I'm experiencing exactly the same problems with 1&1 like described from Petar in the beginning of this thread.
I finally found a "solution" by using the pre-configured moodle from the 1&1-App-Center.
To do this, log in into your 1&1-Ionos account, go to "websites & shops" and "create a new website".
From here you can go to the app-center and find moodle (version 3.5.6). It installs into your htdocs and runs quite fine.
This worked for me.
I also tried to manually update this running pre-made-moodle to 3.7.2. The update worked in general but failed in the end since 1&1 uses an old mysql-version (all the rest in the update-process looked good). I'm sure, the moment they update mysql you can manually update to moodle 3.7.2 and keep the "1&1-settings". If you do so, check all the hidden folders (starting with .) in the moodle-folder, they should also exist in the upgraded version. As far as I understood, this is how 1&1 makes moodle run. I did not find all this hidden folders and files in the moodle-folder when doing a clean manually install from the moodle.zip/tar-files.
hope, this helps a bit
Should help those hosted on 1&1 ... they thank you!
Now I have a question or two ... clarification ...
You installed a 3.5.6 from 1&1's app installer. Did you run the environment check after it was up and running?
Manual upgrade of the app installed Moodle failed because of DB version. Was that all???? DB character set/collations/engine?
You've made reference to "...check all the hidden folders..." need be present in old code as well as in the manually acquired 3.7 code.
Mind sharing what those hidden files/folders were?
Reason I ask ... in a locally extracted .tgz file of code ... there don't appear to be any 'hidden' folders .... just files:
.eslintignore
.eslintrc
.gitattributes
.jshintrc
.shifter.json
.stylelintignore
.stylelintrc
.travis.yml
Were those above what you were referring?
'SoS', Ken
thanks for your input and questions. I'll try to answer them as good as I can.
Since I am completely new to moodle my apologies if some of my comments are rubbish or just obvious for the expert.
> You installed a 3.5.6 from 1&1's app installer. Did you run the environment check after it was up and running?
nope. Did now. Looks like this and seems running well:
>Mind sharing what those hidden files/folders were?
>Reason I ask ... in a locally extracted .tgz file of code ... there don't appear to be any 'hidden' folders .... just files:
> .eslintignore / .eslintrc / .gitattributes / .jshintrc / .shifter.json / .stylelintignore /.stylelintrc / .travis.yml
> Were those above what you were referring?
.eslintignore
.eslintrc
.gherkin-lintrc
.gitattributes
.htaccess
.htgcld34ieljdj.data (Folder, I assume the dataroot, contains cache, diag, filedir, lang.....)
.htxt8cvv.appconfig.php (contains the mysql-DB password)
.jshintrc
.shifter.json
.stylelintignore
.stylelintrc
.travis.yml
Thanks for response and info...
.htaccess
Is typical on such servers/systems as in file contains settings for what version of PHP to run (typically).
.htgcld34ieljdj.data (Folder, I assume the dataroot, contains cache, diag, filedir, lang.....)
Now that's a big difference in docs on Moodle.org and just about any blog/customer FAQ/tutorial etc I've ever seen or read on Moodle. It's what everything else refers to as 'moodledata'. That also illustrates why persons who use such systems need to be aware of that ... so in the config.php file of Moodle code $CFG->dataroot would have to point to full path to a hidden directory ... /path/to/.htgcld34ieljdj.data
If one followed Moodle.org directions for upgrading, moving current code directory (+ config.php) out of the way and replace new code ... copy back config.php into new code to upgrade ... data directory wouldn't be found in new code.
Think I'd be very cautious about a Softaculous or 1&1 upgrade button for Moodle.
And another biggy ...
.htxt8cvv.appconfig.php (contains the mysql-DB password)
Is that the password for DB user setup to run a moodle, or is it the superuser password?
And, of course, the missing php extensions ...
'SoS', Ken
sorry for the delay to your question.
>Is that the password for DB user setup to run a moodle, or is it the superuser password?
it's the chosen user setup for my moodle-installation, not a superuser-password. But it seems to be something temporal by ionos. In the meantime I updated (manually) to moodle 3.8 as mentioned above:
- rename old ionos-installed moodle (3.5)
- unpack moodle 3.8 in the same folder-structure as the original ionos-installation
- backup moodle-db, delete moodle-db, create new moodle-db with actual mysql, restoring moodle-db
- copy back the .htgcld34ieljdj.data - folder, config.php (with new DB-access data) from the ionos-installation to the manual unpacked version (3.5 -> 3.8)
It worked immediately without the strange .htxt8cvv.appconfig.php - file. Seems not to be needed
I also fixed the opcache-warning be learning, that the needed php.ini-file has to be placed in the admin-folder of moodle
The last things driving my crazy with ionos/1&1 is that I'm not able to activate slasharguments whatever I do and that h5p can be installed as plugin but when selecting h5p in "new activity", the h5p-editor is not working (javascript-errors, "loading, please wait"-loop forever). But that's another issue and not for this thread.
To sum up my ionos-odyssey:
- Install moodle (3.5) via the prepared 1&1 app-package (this app automatically creates db on older mysql which does not work with moodle 3.7+)
- rename this ionos-installation of moodle (3.5) as backup
- unpack moodle 3.8 in the same folder-structure as the ionos-installation
- backup moodle-db, delete moodle-db, create new moodle-db with actual mysql, restoring moodle-db
- copy back the .htgcld34ieljdj.data - folder, config.php to moodle 3.8-in-old-folder-structure
- edit config.php with new DB-access data
- fix opcache with php.ini in admin-folder of moodle
- fix codepage by setting dbcollation' => 'utf8mb4_unicode_ci in config.php and in moodle-db
- open: https (not so important for me)
- open: php_extension xmlrpc: possibly not fixable at ionos
- open: slasharguments (driving me crazy), tried with .htaccess, php.ini -> nothing...
- open: h5p plugin editor not working
Thanks for all the help.
Patricio
I don't host with ionos but looks like their script to install a moodle takes what they think is an extra protection (or a work-around) with this:
.htgcld34ieljdj.data
see the dot in front of that directory name?
Typical standalone servers use /var/www/ as home directory for apache user and one can create (manually) a moodledata folder there ... apache user/group can see/use.
Typical (many) hosted servers use public_html and user is kinda in a jail. May not be able to put moodledata outside of public_html and have moodle see it in /home/accountname/ or something like that.
What's in .htgcld34ieljdj.data?
And what's in: .htxt8cvv.appconfig.php
If one were hosted where one is on a VPS (dedicated just to one customer), one could easily install the php xmlrpx extension via package manager .. CentOS 6 or 7 that's yum ... Debian/Ubuntu that's apt-get.
Do you have something like 'EasyApache'? ... which allows choosing PHP version but also which extensions are loading?
If you put a phpinfo.php page at code root and access it directly one should see which php.ini file is being used and in some cases how PHP was compiled.
Slasharguments is really 'AcceptPathInfo' in apache 2.4.
See:
https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo
where it says can be configured in .htaccess
AcceptPathInfo On.
Now if it can't with your hosting, contact hosting helpdesk.
All I can say is good luck!
'SoS', Ken
Hi Patricio,
I was struggling with an identical problem in 3.8+ (hosted by ionos/1&1 aswell). But I think I found a makeshift solution to get h5p running (based on a suggestion by Matteo Scaramuccia https://moodle.org/mod/forum/discuss.php?d=355986#p1436120):
I created a .htaccess file in my moodle folder with the following content:
SetEnvIf Request_URI "^(.+\.php)(/.+)$" PATH_INFO=$2
Hope that helps!
Best regards from Potsdam
Hi Arved,
thanks for the help. Unfortunately, it did not work on my ionos-installation.
Although the issue seems to be known, there's not much activity there:
https://tracker.moodle.org/browse/MDL-66879
regards from Berlin
Hi,
I got same problem and I found out that there must be an error in CSS.
view-source:http://YOURDOMAIN/theme/styles.php/boost/1593501375_1/all
will reuslt in
theme was not found, sorry.I was checking if theme-direictery can be read. but found no error.
Until now I did not solve it
$CFG->slasharguments = false;
Side note: I even tried installing the Ionos version of Moodle. And they add $CFG->slasharguments = false; to their config!!!!
I've done the the following.
I added the "AcceptPathInfo On" into my .htaccess and a "cgi.fix_pathinfo = 0" in a php.ini file in my moodle directory. But Ionos is ignoring this.
But I found a solution!!
Ionos requires the php.ini to be in EVERY directory that has a script. Once you have the install done, then do the above configuration and do a link in every directory back to your original php.ini file. See the following.
I suspect this will work for other shared hosting providers as well.
Hi folks,
Having battled with 1&1 Ionos with this issue since first installing Moodle in March I thought I'd quickly share the solution!
As Mikel says, you need php.ini (and set_path_info.php) in *every* folder, but there's an easy way to do this (which is easy to update as well). After many hours on the phone, a helpful tech support agent (finally!) sent this over to me:
- - - - - - - - - - - - -
1. Create a php.ini file (if you don't have one already)
2. Paste this code inside your php.ini and save your changes
auto_prepend_file = set_path_info.php
3. Create a set_path_info.php file
4. Paste the code inside set_path_info.php and save the changes
<?php
if (getenv('ORIG_PATH_INFO')) {
putenv("PATH_INFO=".getenv('ORIG_PATH_INFO'));
}
if ($_SERVER['ORIG_PATH_INFO']) {
$_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];
}
if ($_ENV['ORIG_PATH_INFO']) {
$_ENV['PATH_INFO'] = $_ENV['ORIG_PATH_INFO'];
}
?>
5. Create a symbolic link (symlink) of your "php.ini" & "set_path_info.php" in every subdirectory, using SSH terminal, starting in the root of your Moodle installation:
find -type d -exec ln -s $PWD/php.ini {}/php.ini \;
find -type d -exec ln -s $PWD/set_path_info.php {}/set_path_info.php \;
- - - - - - - - - - - - - - - -
The 'symbolic links' make it appear to the server that php.ini and set_path_info.php from the root of your Moodle installation are in *every* subdirectory.
'slasharguments' issue solved! Thank goodness!
There's another issue to watch out for on a 1&1 Ionos shared server (this broke my Moodle installation last week!) - there is a file quota limit AND a disk space quota limit, despite the contract being for 'unlimited' space. My default disk quota was set to 50GB, which they increased to 75GB when this issue arose. They cannot increase the file quota, sadly.
Where this gets tricky is in running backups: What I recommend is limiting the number of Moodle installs to keep well within the file quota, then if you need to back up the Moodle directory, just zip/pack it to a .zip file.
I hope this is useful to someone and can help them avoid the HOURS that I spent on the phone to tech support explaining the same problem over and over again!
All the best,
Patrick