I'm using wordpress plugin Duplicator followed all instructions but I get this when I transfer it on a temporary website page.
Warning: session_start() [function.session-start]: Cannot send session
cookie - headers already sent by (output started at
/home/public_html/temp/wp-content/plugins/wp-e-commerce-product-showroom/wp_e_showrp.php:469)
in
/home/public_html/temp/wp-content/plugins/wp-e-commerce/wpsc-core/wpsc-constants.php
on line 17
Warning: session_start() [function.session-start]: Cannot send session
cache limiter - headers already sent (output started at
/home/public_html/temp/wp-content/plugins/wp-e-commerce-product-showroom/wp_e_showrp.php:469)
in
/home/public_html/temp/wp-content/plugins/wp-e-commerce/wpsc-core/wpsc-constants.php
on line 17
Warning: Cannot modify header information - headers already sent by
(output started at
/home/public_html/temp/wp-content/plugins/wp-e-commerce-product-showroom/wp_e_showrp.php:469)
in
/home/public_html/temp/home/public_html/temp/wp-includes/pluggable.php
on line 866
Then I read some solutions posted in wordpress forums:
Solution:
Create a php5.ini and save it in your root folder. If you have various websites under one server, then it will be saved where you can view all the websites' folders.
Create a folder in the root named "tmp" (without "s)
Type this inside the php5.ini :
session.save_path = "/home/content/##/#######/html/tmp"
upload_tmp_dir=/tmp
*The #s are replaced by what your hosting provider gave you. In Godaddy, when you enter your Hosting Control Center it will be the
Absolute Hosting Path under Server.
They said it worked but not for me. Can you help me identify where my save_path?
Is this solution really working? Do you have any other option to solve this problem?
To find your absolute path which is needed for your save_path, log in to your Hosting Control Center. Once logged in you will see the Server column in the middle of the page. At the bottom of this column is your absolute path. Simply append /tmp to the end of this after creating the folder in your root.
Related
I've created my bucket on Google Cloud with the appropriate site title, and installed Wordpress.
I then pointed Wordpress to my domain, but when I go to the domain I get the following error:
This XML file does not appear to have any style information associated
with it. The document tree is shown below.
<ListBucketResult xmlns="http://doc.s3.amazonaws.com/2006-03-01">
<Name>shop.site.com</Name>
<Prefix/>
<Marker/>
<IsTruncated>false</IsTruncated>
</ListBucketResult>
It was doing this before I installed Wordpress as well.
Some kind of security issue I think, but I've edited my bucket permissions and my default web page to be index.php but it's still showing this.
Any ideas?
I got the same error when hosting a new static website until if used the instructions here: https://cloud.google.com/storage/docs/gsutil/commands/web
That may or may not be the problem in this case, though.
You must use the gsutil command line to set the main_page_suffix.
gsutil web set -m index.html -e 404.html gs://example.com
I've been looking around for hours on how to fix this. Every answer I look at involves using a cli to assign permissions and change user groups and the like. Unfortunately, my host will not allow me to use SSH so all I can do is use the Plesk 12.5.30 cpanel. This means my options are very limited in terms of problem solving.
So far I have tried assigning 755 permissions to everything via my FTP client, creating a new FTP user, and moving the forbidden file to the root
Relavent info:
the only forbidden file is my main css file
the files are sitting in a subdomain
creating a blank HTML template file via the cpanel in the same folder as the css file does not throw a 403
putting the css in a style tag in the HTML template causes a 403
I hate my host but I can't switch
Is there anything I can do short of pleading with my boss' boss to change hosting providers?
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.
I want to do developments on my client's website but by making a clone of it. So, main website url is: http://website.com and the clone i am trying to create is: http://test.website.com.
So far i've done the following:
copied entire root directory into public_html/test dir (with folders config,field,FirePHPCore,fontyourface,includes,js,misc,modules,scripts,sites,styles and themes)
created a subdomain in cPanel for test.website.com
checked the file settings.php (inside sites/default folder) for $base_url but found it commented, so left it as it is unchanged.
copied db via phpMyAdmin and updated the new db details in settings.php (inside sites/default folder).
inside the table variable, two rows with the name securepages_basepath and securepages_basepath_ssl. Changed their values from http://website.com to http://test.website.com (using the variable_get and variable_set functions).
Now i can access http://test.website.com but when i click on login (from header) it takes me to http://website.com/user and if manually type http://test.website.com/user and login then it takes me to http://website.com/users/admin then i have to manually type in correct address http://test.website.com/users/admin.
And when i logout, it again takes me back to http://website.com.
So i want to know how can i completely make it to work on http://test.website.com?
Are there more variables to change?
And how i can make 100% sure that the test site is only using test and not the live site. I am afraid of messing up live website.
Please advice, thanks!
I fixed it by disabling the secure pages from inside the mysql database. It was inside variable table and securepages_enable field. It was in blob so i had to download the blob first and opened it in notepad and changed the value inside it from 1 to 0 and then uploaded it back by updating the securepages_enable field.
I had to do this because after logging in from my test url, the urls were redirecting back to the live website, so whatever change i was making, it was all affecting the live site.
Hope this helps to someone with similar case. Thanks!
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