These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for FIXED: PHP settings for Drupal? on the new forum.
All of my Drupal sites are displaying the same group of errors now that I moved them to my VM server. The sites all have different modules and those exact modules and databases were working on my old Cpanel hosting account so it has to be something with my setup. The errors are php, but it's about datatypes so I think it might be my MySQL setttings. Could someone take a look.
I get the errors below about 50% of the time and the page will display "access denied" whether I'm logged in or not. The specific module referenced changes, but as I said it was working fine on the previous host as-is.
# warning: array_fill() [function.array-fill]: Number of elements must be positive in /home/williamswebsites/public_html/includes/database.inc on line 241.
# warning: implode() [function.implode]: Invalid arguments passed in /home/williamswebsites/public_html/includes/database.inc on line 241.
# warning: array_keys() [function.array-keys]: The first argument should be an array in /home/williamswebsites/public_html/modules/user/user.module on line 502.
# user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/williamswebsites/public_html/modules/user/user.module on line 502.
# warning: array_keys() [function.array-keys]: The first argument should be an array in /home/williamswebsites/public_html/sites/all/modules/logintoboggan/logintoboggan.module on line 433.
# warning: in_array() [function.in-array]: Wrong datatype for second argument in /home/williamswebsites/public_html/sites/all/modules/logintoboggan/logintoboggan.module on line 433.
# warning: array_keys() [function.array-keys]: The first argument should be an array in /home/williamswebsites/public_html/modules/block/block.module on line 406.
opening taostmasters.com gives errors about the williamswebsites.com database turbocameroproject doesn't exist?
I reckon something went wrong in the move of the sites. I would first check the files in /home/williamswebsites/public_html/includes/database.inc on line 241 and the others to learn what it is complaining about exactly.
note that you also have dns problems
As for the nsatoastmasters.com giving error about williamswebsites...it's supposed to. It is an alias of williamswebsites.com in Virtualmin. The Drupal multisite installation handles which database to load based on the url. I'm a Drupal developer so I know Drupal very well and this isn't a code issue. Something is not setup right on my CentOS/Virtualmin box. I'm a newb at linux.
What DNS problems do you see? Could you be more specific?
Thanks.
as for dns: For ns1.williamswebsites.com the parent reported: ['72.14.187.228'] and your nameservers reported: ['72.14.168.72']
ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns2.williamswebsites.com
SOA MNAME (williamswebsites.com) is not listed as a primary nameserver at your parent nameserver!
Primary nameserver: williamswebsites.com Normally this is the hostname or something like ns1.williamswebsites.com
I don't know Drupal, but the permission errors and database errors I can't directly trace to virtualmin. Per haps it is a file permission. Are the files 644 and dirs 755, also do all files belong to the user (you didn't upload the files as root?)
Can you install a Drupal site in some subdirectory but through the install scripts in virtualmin and then import a sql dump into the database as a test?
turbocamaroproject.com has serious dns errors and isn't reachable One or more of your nameservers did not return any of your NS records.
Ok. I fixed the DNS errors.
Now....any other ideas on these errors? MySQL config? PHP config? What do you think?
Fixed:
php.ini
session.save_handler = user
Not sure how it happened but I had an 's' on the end of user.