I am trying to reinstall drupal after I get this error:
Fatal error: Maximum execution time of 120 seconds exceeded in C:\wamp64\www\drupal\core\lib\Drupal\Core\PageCache\RequestPolicy\NoSessionOpen.php on line 3
For solving this error, I've set max_execution_time = 300
I deleted the drupal folder from wamp64\www and again pasted another copy of drupal folder. When I try to reinstall drupal, I am getting the message,
Drupal already installed
To start over, you must empty your existing database and copy default.settings.php over settings.php.
To upgrade an existing installation, proceed to the update script.
View your existing site.
but I've not completed the steps Install site and configure site while installing drupal.
When I click on existing site, the page asks for username and password. I've not set username and password for it. How to solve this problem? Please help.
I know you have solved your problem already but for anyone else that stumbles upon this.
Option 1 (recommended): use Drupal's command line tool, drush. "drush sql-drop" will drop all database tables, launch the installer.
Option 2: Change the database information in the settings.php file (webroot/sites/default/settings.php). i would not recommend deleting the file as the installer requires settings.php
Related
In Wordpress i can get this error message while update into wordpress4.4
how to reset my website
Fatal error: Call to undefined function wp_installing() in /home/u365143419/public_html/keerthikaprinters/wp-includes/functions.php on line 1354
Here's what helped me to fix the problem:
1) create a backup of all files and the database (highly suggest)
2) Delete all files and folders except for the folder wp-content. You will need this folder. It contains all the files for your theme and plugin.
3) Replace all the wordpress files in the install download EXCEPT for wp-content.
4) Update wp-config.php with your database credentials. They can be retrieved in your current wp-config.php.
5) Test your website. If all seems well login into your admin panel and see if the database needs updated.
Hope it helps, if you didn't already solve the problem.
The function wp_installing is a new function in /wp-includes/load.php, as of WordPress v4.4.0.
From my research/experience, there are 2 reasons for the problem (and it could be both):
1) Corrupted WordPress files, for example caused by an incomplete update installation, in which case you need to reupload (eg. via FTP) the core WordPress files (ie. /wp-admin/, /wp-includes/, and the .php files in the root of your WordPress site (although be careful with wp-config.php if you have a dev environment version too!)). At the very least check that /wp-includes/load.php includes the new function definition for function wp_installing().
2) WordPress becomes "confused" by an update installation (for example by a failed update), thinking that it is in the installation process, when it is not (or when it failed partway).
After making sure that 1) was not the problem (by doing a file comparison between the 'out of the box' WordPress files (from the WordPress zip download), doing a bit more research, and pulling my hair out), I found that there is a WordPress PHP flag WP_INSTALLING that the core uses during an update as part of handling the installation process. At my wits end I temporarily put the following in wp-config.php:
define('WP_INSTALLING', false);
and reloaded my failed/broken site, and lo and behold, my WordPress site started working! I then remove this line, and the site has been working fine since.
I can only assume that because my first attempt to update WordPress using the automatic WordPress update feature failed, and that when I then FTP'd up all the WordPress core files in attempt to do a manual update to fix it, that WordPress was somehow confused as to what state it was in (which even restarting the web server didn't fix). Forcing the WP_INSTALLING flag temporarily to false thus got WordPress sorted out internally, and allowed things to operate normally again. Interestingly after doing this, WordPress prompted me to update my database (which I did), and which seems to me to confirm that the WordPress update installation got interrupted midway and was the cause of my problems/this fatal error/WordPress thinking that the WP_INSTALLING flag was actually currently set as true.
For some reason my admin screen just hangs with some javascript errors. I have it installed on xampp on windows 7 ultimate 64bit. What could be causing this? Ill post a screenshot of the errors any help would be nice! p.s. This is my first time installing silverstripe ever so be nice. :)
This sort of things usually occurs when combined asset files cannot be created. Make sure the web server user has write access to the assets/ and assets/_combinedfiles folders, then go to your-site.com/admin/pages?flush=1.
Alternatively, since this is a local install, run in dev mode. There are instructions in the documentation on how to set this.
As indicated by #simon_w, this issue occurs due to the folder permissions:
In your local environment, in addition to the way via yml config, you can just put the following in _config.php inside mysite folder.
Director::set_environment_type("dev");
In dev mode, the installation doesnt need to write to assets/_combinedfiles. However, you had better have write permission for assets folder anyway.
So, just increase permissions for assets and directories under it. Uploaded files are also stored there, if not sufficient permission, you can't upload files from the admin panel. Other functionalists may also be affected.
I've just migrated a client site to her production server using the latest version of BackupBuddy v3.0.40, and at first glance everything looks dandy, but on closer inspection, most WP file functions are borked: update wp, upload images, upload plugin.
I've done this a ton of times (several times on this host), and don't know why its not working here
I suspect it has to do with the tmp directory, but i can't see a problem..
another possibility is that a script (installatron via cpanel maybe interfering.. i notice that there are upload folders created for all months up to 2016! i read about this being a solution to permissions issues in WP's past)
This is what I've tried:
changing the wp-media upload location to the default, changing the 'store in year/month' setting and general wiggling. this was imported as '/home/###/public_html/wp-content/uploads' which looks correct, but unnecessary, the default is wp-content/uploads. neither work.
changing the permissions on wp-content and uploads dir to 777 (not all contents)
adding a line to wp-config.php:
define('WP_TEMP_DIR', ABSPATH . 'wp-content/'); no dice
uninstalled all traces of the installatron scripted wp installation (no files or db remain)
repeating the migration (same backup file, identical results)
confirming that:
i can create new posts, just not upload media
it works on the staging server (same host)
safe mode is off
apache is running as user, tx suPHP
the files were extracted by php via the browser
i've compared phpinfo to other working sites and dont notice anything out of the ordinary
hope you can shed some light!
thanks, Tim
image upload error:
“envelope-9887.jpg” has failed to upload due to an error
The uploaded file could not be moved to /home/###/public_html/wp-content/uploads/2012/07.
wordpress update error:
Download failed.: Destination directory for file streaming does not exist or is not writable.
plugin install error:
Download failed. Destination directory for file streaming does not exist or is not writable
sometimes when migrating you may have to look through the database options table and change a few entires, ie:
from the old site structure it could be: /home/yoursiteid/public_html/wp-content/ etc..
but on the new server the structure could have changed?
ie: /home/differentuserid/wwwroot/wp-content/
edit a file on the server to include :
echo getcwd() . "\n";
just to see if the home directory is the same as your current server or if its changed from your old sevrer, have a check in your database options table and update the entires which ref the old dir structure..
I found, eventually, that I'd overlook the line
define('WP_TEMP_DIR', 'old-hard-link-here');
which I believe was nestled directly under the wp salts, camoflaged to the tired eye! Simply removing that line and setting the media path to the default fixed the issue.
I believe that that line was installed by the cPanel script 'Installatron'.
Case closed
I have a problem when trying to manually upload a new plugin in wordpress.
Uploading media is working perfectly, and also automatically install plugins work as it should, but manually uploading plugins generate an error message:
The uploaded file could not be moved to C:\inetpub\wwwroot\Wordpress/wp-content/uploads/2010/11.
I have checked permissions on wp-content and uploads and it is set to Everyone. I do not think there is anything wrong with permissions since I can upload images, and I see them inside my uploads folder.
I think there might be a problem with the slashes beeing incorrect, does anyone else have this problem?
I'm using IIS7, Windows Server 2008 and Wordpress 3.0.1. Everything is installed with Microsoft Web Platform Installer.
I know this is way late in answering, but I hope someone may find it useful.
This is most likely a problem with the settings involving the temporary upload location.
Here is what I did to solve a similar problem:
Ensure that you are editing the correct initialization file. Putting:
in a test.php file and executing it from your web browser will get you the setting.
Look for the setting for "Loaded Configuration File"
In that configuration file search for (or add if missing) the following setting:
upload_tmp_dir = "c:\inetpub\temp\uploads"
Ensure that c:\inetpub\temp\uploads exists and is writeable by everyone. You can tighten this up with specifying the IUSR account if you wish.
Recycle/Restart the IIS worker process. Your choice here as there are a number of ways to accomplish this.
I found a good bit of this info by referring to c:\tmp\php_errors.txt. The fastcgi.logging should be enabled by default on windows installations.
Just wanna add a solution to the good Harold's answer for PHP.
Despite changing the setting "upload_tmp_dir", I was still getting the same error message The uploaded file could not be moved to C:\inetpub\wwwroot\Wordpress/wp-content/uploads.
So i have changed also the setting "upload_max_filesize"
upload_max_filesize=16M
(16M or greater depending on the wordpress's themes size file)
Hope it helps someone who was stuck like me.
With Filezilla
directory uploads>2010>11 to set permision 777
I'm copying my Drupal installation to another folder and I've copied the related database.
When I run update.php on the new copy I get the following error:
http://dl.dropbox.com/u/72686/updateError.png
should I disable some modules.. or is something about Drupal core ?
(I'm using version 6.16)
I've flushed all caches and the website is offline.
thanks
You have to log in to run update.php...
actually I'm also wondering how could you run update.php without being logged as administrator O_O
For the error... looking at the line reported in the error:
list($module, $version) = array_pop(reset($_SESSION['updates_remaining']));
you can see the use of $_SESSION array;
Probably you don't have any php sessions if you are not logged in...