I have the newest wp e-coomerce plugin (Version 3.8.12.1) on my wordpress Version 3.6.1 installed
I'm just trying to change username (email address) in paypal standard settings of the store and it simply doesn't work - the address is not being updated neither with Update button for the option nor with Save changes button below all options.
Is it a bug? Or I'm doing something wrong?
I did check with Live HTTP headers and I can see the new values are captures correctly but then passed to the address which gives 302 error:
HTTP/1.0 302 Moved Temporarily
Date: Mon, 23 Sep 2013 08:04:17 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Location: /wp-admin/options-general.php?page=wpsc-settings&tab=gateway&settings-updated=1
Content-Length: 0
Content-Type: text/html
X-Cache: MISS from proxy1
X-Cache-Lookup: MISS from proxy1:3128
Connection: keep-alive
But then on tabs which are saved correctly I get the same headers for /wp-admin/options-general.php as above so looks like this is not where the issue lies?
Related
Bit of an odd one.
I noticed some query string stopped working on page load for a page on my website. Upon checking the network console of chrome and firefox, I can see that the page is returning a 403 forbidden error. This is odd, since the page seems to be loading correctly (except for query string not applying on page load).
It's the only page on the site that seems to be doing it.
Response Headers:
cache-control: no-cache, must-revalidate, max-age=0
cf-cache-status: MISS
cf-ray: 463904819f55a71f-DUB
content-encoding: br
content-type: text/html; charset=UTF-8
date: Tue, 02 Oct 2018 17:51:33 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://ygoprodeck.com/wp-json/>; rel="https://api.w.org/", <https://ygoprodeck.com/?p=7620>; rel=shortlink
pragma: no-cache
server: cloudflare
status: 403
vary: Accept-Encoding,Cookie,User-Agent
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: IE=edge,chrome=1
x-xss-protection: 1; mode=block
I'm not sure how it can both get a 403 and load properly at the same time, very odd.
The page in question: https://ygoprodeck.com/deck-search/
Found the issue.
On the root of my site, I had a folder called "deck-search". No idea how it got there but it was causing issues. Removing it fixed it.
I want to install & configure my WordPress site in /journal like:
https://example.com/journal/
After my installation, when I try to access /wp-admin, they say cookie settings haven't been configured within my browser and I fail to log in. When I hit curl:
$ curl -I localhost/journal/wp-login.php
HTTP/1.1 200 OK
Date: Tue, 13 Feb 2018 12:02:28 GMT
Server: Apache/2.4.6 (Amazon Linux 2) PHP/7.2.0
X-Powered-By: PHP/7.2.0
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/journal/journal/; secure
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=UTF-8
I suppose the cookie path being /journal/journal/ is the reason I can't log in properly. What kind of additional configuration is needed to set my cookies properly?
We have used fishpig extension in magento 1.9
We have worked on staging server like https://example.net./staging
I am facing auto login error message in magento:
Please check this Error message "error message "WordPress Auto Login Failed: HTTP/1.1 403 Forbidden Date: Thu, 07 May 2015 09:52:53 GMT Content-Type: text/html; charset=UTF-8 Connection:
close Set-Cookie: __cfduid=d55dca8b4d7161c66a76be98b36895aae1430992373; expires=Fri, 06-May-16 09:52:53 GMT; path=/;
domain=; HttpOnly Cache-Control: max-age=10 Expires: Thu, 07 May 2015 09:53:03 GMT X-Frame-Options: SAMEORIGIN Server: cloudflare-nginx CF-RAY: 1e2c08de44eb094a-DFW"**
Please Suggest me how to remove error message ...
Unfortunately, there seems to be an issue with the auto-login feature when using Cloudflare, as you can see here: http://fishpig.co.uk/magento/wordpress-integration/auto-login
I had the same problem, you can access the Wordpress admin by navigating to www.yourwebsite.com/wordpress-folder/wp-login.php
CloudFront ignores my cache header and my pictures have to be picked up from the server again after a while.
~$ curl -I http://d2573vy43ojbo7.cloudfront.net/attachments/store/limit/64/3720c5574063aebc90511061b99de858740ad764c6981d2bf30ff121ada0/image.jpg
HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 1645
Connection: keep-alive
Server: nginx/1.4.1
Date: Thu, 12 Feb 2015 14:37:41 GMT
Status: 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers:
Access-Control-Allow-Method:
Cache-Control: public, must-revalidate, max-age=31536000
Expires: Fri, 12 Feb 2016 14:37:41 GMT
Content-Disposition: inline; filename="image.jpg"
Last-Modified: Thu, 12 Feb 2015 14:37:41 GMT
X-Content-Type-Options: nosniff
X-Request-Id: 239b0fda-cae9-452f-9d1b-ccbf035bbf69
X-Runtime: 3.457939
X-Cache: Miss from cloudfront
Via: 1.1 6cde3c778df412041adc7610331b57bc.cloudfront.net (CloudFront)
X-Amz-Cf-Id: yicAkZYc5XpowKRFMOXDKSJKBMWZ4kq2B3vLK8Q-Py124D8lQq_1lg==
I tried to get the same file yesterday and then it was the same, after the second time i tried it was reached and served by CloudFront but not anymore. It's the same for all my images. They are cached but are removed from the cache after a couple of hours.
What's wrong? My cache behavior settings on CloudFront is set to default and it uses Origin Cache Headers.
Take a look here: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that are more popular.
It means that object is not popular enough to stay in cache for a longer time. If you have enough viewers hitting this object AND this particular CloudFront location, it would have stayed in cache longer
I write a c program to crawl blogs. It works well until it meets this blog: www.ipujia.com. I send the HTTP request:
GET http://www.ipujia.com/ HTTP/1.0
to the website and get the response as below:
HTTP/1.1 301 Moved Permanently
Date: Sun, 27 Feb 2011 13:15:26 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4
Perl/v5.8.8
X-Powered-By: PHP/5.2.14
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Sun, 27 Feb 2011 13:15:27 GMT
Location: http://http/www.ipujia.com/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
This is strange because I cannot get the index page following the Location. Does anyone have any ideas?
The Location field in the response contains a malformed URI.
Location: http://http/www.ipujia.com/ (notice the protocol error)
Should be
Location: http://www.ipujia.com/
Unless you are in control of the server there is little you could do here.
To solve it could you not parse the "Location" response and attempt to extract a valid URI from the it?