How to solve this error in moodle ? and setup in localhost? - http

Fatal error: $CFG->dataroot is not configured properly, directory does not exist or is not accessible! Exiting.

You need to check 'config.php' in your moodle installation files directory.
There you can find a line like below, which shows your directory name (it seems empty as per your error, you need to define path here) - in this directory/folder your moodle media uploads get store.
$CFG->dataroot = '/var/moodledata';
Moreover, after define this you will require to give Read,Write,Execute permissions to this folder.
(here '/var...' mentioned as Ubuntu directory structure, in localhost you need to mention respectively)

Related

How to permanently change the default working path of julia?

I was able to temporarily change it with the following command, but after reboot the working path still changes to C drive.
cd("D:\\jl files”)
As it is explained in the Julia Manual Getting Started section the simplest thing to do is to add the:
cd("D:\\jl files")
line to your ~/.julia/config/startup.jl file (this is a Linux path; if the file does not exist then you should create it with this single line). Since you are on Windows then ~ part should be replaced by default is your user profile folder (it should be possible to check it with ENV["USERPROFILE"] command in Julia). However, if you have a custom installation the .julia folder can be placed in some other folder so you need to check it on your system.

Missing org.sonatype.nexus.cfg file, how to proceed?

Nexus OSS 3.7.1-02 running on RHEL 7. I have several repositories on it and I am able to publish and retrieve packages and jars, therefore, I presume that the setup is working correctly.
In the official documentation, I am referring to the 'Serving SSL Directly' section which uses the embedded Jetty server for serving https connections.
I am unable to find the file '$install-dir/etc/org.sonatype.nexus.cfg' mentioned in the documentation and there are a couple of config. around this file. I executed a find command for that file on the root directory but the file doesn't exist at all.
Another confusing step is:
Edit $install-dir/etc/org.sonatype.nexus.cfg. Change the nexus-args
property comma delimited value to include
${karaf.etc}/jetty-https.xml.
Now there's neither any directory under the 'karaf' directory nor does the file exist there but I found one jetty-https.xml file under nexus-3.7.1-02/etc/jetty.
How shall I proceed?
That isn't the official documentation, it's the documentation for "3.0". The official documentation is here: https://help.sonatype.com/display/NXRM3 (unversioned).
Specifically, I suspect you're looking for this: https://help.sonatype.com/display/NXRM3/Configuring+SSL.
Anyway, that file was replaced in an older version.
It now resides in ${data-dir}/etc/nexus.properties.

Move symfony vendor outside the root project

I want to speed up my symfony2 project on my vagrant box, so I want to move my vendors outside the project folder.
I have install them in /home/vagrant/www/simtp/vendor, but I got a permission error when the autoload.php is included.
Warning: require(/home/vagrant/www/simtp/vendor/autoload.php): failed to open stream: Permission denied in /var/www/simtp/app/autoload.php on line 11
Fatal error: require(): Failed opening required '/home/vagrant/www/simtp/vendor/autoload.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/simtp/app/autoload.php on line 11
I have already tested to change permission with chown, before it was "root", and now it is "www-data" (like the old vendor folder). I have already too tested to change chmod for 777.
But nothing work ... :/
Ps : My cache folder is empty.
What can I do?
Thanks.
I am no expert in this, but since no one else replied, I think easiest solution would be moving vendor files to directory that is not in other user's home directory. in this case:
/home/vagrant/
to let's say:
/var/www-vendor/simtp/app/
this vendor directory should have chown compatible with apache worker (so it would have access)
you can also try solutions described here:
https://unix.stackexchange.com/questions/91488/allow-a-user-to-read-some-other-users-home-directories
as far as I know despite standard permissions, user home directories are especially protected, that is the reason you have this issue.
you also didnt stated what linux distro you are using so you could consider adding this to your question so others would have less work to do.

WordPress update failing

I'm having a problem when trying to update WordPress to the latest version I get the following error:
Download failed.: Destination directory for file streaming does not exist or is not writable.
Installation Failed
I'm also having the same problem when uploading images, it fails and gives the following error
has failed to upload due to an error
The uploaded file could not be moved to "the website path and then uploads directory"
I have checked the permissions of the folders and the folders themselves are set to 755 & the files inside them set to 644.
Could anyone tell me why it would be doing this?
Where running a plesk server.
Thank You,
Mark
Are there any more error messages, probably also in the servers log files? Probably the download for the update should be done to /tmp and you are not allowed to store files there? Try setting the constant WP_TEMP_DIR which should change the directory. Put something like this in your wp_config.php:
define('WP_TEMP_DIR', ABSPATH . 'wp-content/');
The permissions you're using seem reasonable, but they will only work if the FTP user that WordPress is using (set in your wp_config.php file) is the same as the owner of those files/folders.

After upgrading Wordpress, I get a fatal error "Call to undefined function require_wp_db()"

I followed instruction as mentioned in Wordpress, but I still got the error and referred Google and I was shocked to see many blog have same problem and they are not fixed yet and those blogs are indexed in Google, please try searching "Call to undefined function require_wp_db()" or find here
Google search result
Any advice how to fix? Thanks in advance
This will occasionally occur if you do not upload wp-config.php or all of the other files that have changed between versions.
Download a clean copy of the WP version you are trying to upgrade from the WP Release Archive.
Update wp-config.php with your database details, secret keys, etc.
Delete all files except for /wp-content on your server (hopefully you have kept all of your custom enhancements relegated to the /wp-content/themes directory as they recommend - otherwise you will have to diff against each individual file unless you've kept good track of your changes).
Upload all of the clean files except for the /wp-content directory
Run /wp-admin/upgrade.php
This question might have been misplaced on this site, but the cause of this error could be a general programming bumble.
Your problem could stem from ambiguous include paths. When using include / require / include_once / etc... if the filepath is not absolute, the file that gets included might not be the one intended. Read why here. To fix an ambiguous include directive, prefix the relative path with dirname(__FILE__).'/'.
A plugin or even your theme could be the culprit. A regex like this could help you find cases of this: (include|require)(\_once)?\s*\(?\s['"][^\/]
Example
I had a Wordpress theme for a multisite install that included a file like so:
require_once('sites.php'); Because sites.php was a file in the same directory, (and because the server's include path included "." -- the current directory), it worked.
However, because sites.php also existed at /wp-admin/network/sites.php, so this line caused the following error when trying to access the network dashboard:
Fatal error: Call to undefined function _get_list_table() in /www/OCE/WEBEDITOR2/wp-admin/network/sites.php on line 19
After trying the instructions in the other answer to no avail, I fixed my problem by finding and changing this line to:
require_once( dirname(__FILE__).'/sites.php' );
Note: In most, cases, Mark's suggested solution should be employed first in trying to fix this error after upgrading Wordpress, if only to eliminate other possible issues.

Resources