Trying to optimize a wordpress site. When a browser requests static images, it sends cookies with the request from the main domain, but the server ignores the cookies. These cookies are unnecessary network traffic. To workaround these issues, I am trying to make sure that static components are requested with cookie-free requests by creating a subdomain. And it also helps in parallel requests thereby loading my site faster.
I created the subdomain accordingly, I changed the the uploads_image_path in the "wp-admin/options.php". And every image seems to be redirecting to my subdomain, except all my woocommerce images.
Example:
example.com/wp-content/uploads/2018/07/image_name.jpg
should change to
uploads.example.com/2018/07/image_name.jpg
If I can't redirect my my woocommerce images, it renders that one strategy absolute, because woocommerce contains most of my images. Am I missing something?
Solved it, changing the path on "example.com/wp-admin/options.php" does not write permanent changes ". I had to go directly to the options table in the database, change the the values for "upload_url_path" and "upload_path" to my subdomain.
Related
Our website https://www.diamir.de is build with laravel. when we try to load the site in an iframe on another domain, the session is regenerated with every request. the session cookie is send to the browser. but it seems laravel is not able to read it on the next request and therefore regenerates the session.
how can we enable sessions when the site is loaded in an iframe on another domain? is this even possible with the security settings in modern browsers?
thanks.
iFrames are largely locked down windows to view other content inside your website. They were a useful way of hacking things into sites, but have been replaced in a lot of scenarios.
For your particular scenario, showing the site fully on another domain, there are other, better ways to reference the same site from multiple domains.
Personally, I'd redirect in most scenarios, all where an iFrame would work. This results in a user going to any secondary domain, and being redirected to the primary domain. Usually done with a 301 permanent redirect.
However, the one occasion where I need the site sitting on multiple domains is when the site is themed on other domains. In a lot of these cases, it's preferable to fork the site and make changes as needed, but in those that need the same code base and just a theme over the top, I'd simply have the server (Apache, NGINX, or any other server) listen to multiple domains all serving the same site.
I have a weird situation with a client:
The root directory has a custom built CMS serving the site.
They want to rebuild the site in stages as it is very big.
So they want the new site in Wordpress and for the first stage just to build specific pages in Wordpress.
So obviously I would install WP in a sub directory or a different directory than root.
BUT, they want the pages served by WP to not indicate a different URL path so if we create a page called page1 the URL needs to be:
http://domainname.com/page1 not
http://domainname.com/wp/page1
Obviously if a browser navigates to:
http://domainname.com/page1
the CMS installed in root will try to serve the page and return a 404.
So my thinking is it must be possible to add a bunch of rules in the root folder htaccess (or with PHP) that check a list if the incoming request is for a URL we indicated in the list is meant to be served from WP, then to pull the files from the WP sub directory (bypassing the CMS installed in root) and rewrite the URL to root.
So if I go with my browser to:
http://domainname.com/page1
I will get the WP page
and if I go with the browser to:
http://domainname.com/wp/page1
it will server that page but with a 301 redirect to:
http://domainname.com/page1
Makes sense? Anyone know if this is possible?
I have tried but my htaccess/apache skills are not high enough to solve this one.
Thanks
You are in a very complicated position, in one way that could be very easy if your client doesn't bother with the subfolder which is pretty reasonable and cheaper because you don't have to spend time trying figure out how to get a clean URL, instead of that you can have a semantic URL like:
http://domainname.com/page/page1
So you have your Wordpress installation in the "page" folder and everything looks transparent for the user.
On the other hand, if you what create re-directions for each page you create in the new Wordpress you can do it in the Cpanel if you have access to the server.
The problem is you have to do after a new page publication.
In terms of SEO, you are getting a Soft bounce, which is not terrible but not terrific.
when you migrate all the content to Wordpress you have to delete all those redirections and will be more work to do in terms of SEO
The bottom line is if you have enough arguments for why you client could let you do it in the easy way that can help you a lot and save a lot of time.
I have a drupal site connected to another non-drupal site. (All php) They have Single sign-on. Some info is stored in a cookie. So when a user signs in in the Drupal site and clicks the link to the other site he is automatically signed in in the next site. The new (or existing) user gets generated (or updated) automatically every time.
Now the problem:
Somehow some of my changes to a couple of pages regarding this authentication are ignored when I use the HTTPS:// link. It looks like it keeps checking the old files... Like they are stored in a hidden place? When I change to HTTP:// suddenly it takes the new modified files...
And it only happens to files about the authentication process. All my other commits to other parts of the second website work like normal. Just these couple of authentication files get ignored.
Does anybody knows why https behaves like this?
Could this be server caching or php caching ?
I'm going to post the answer to my own question so hopefully I can help someone else with a similar problem.
There were 2 files with the same name.
The HTTPS login file was in the private_html folder.
the http login file was in the public_html folder.
They both had the same name. So when I updated the http file and pushed it to the server, the https login file stayed untouched. And since the https login file was not in the git repository I couldn't find it locally, but only on the server...
Problem solved, so no caching problems at all.
I build a client website and business system using html+php+mysql and both runs on same domain.
Recently, I feel like it would be better to separate the website and use wordpress so that the client can update their own contents instead of me doing this everytime they need to change something.
As, my client is in low budget, I was thinking whether it would be possible to run both the wordpress and business solution on same domain. If I run the business solution under sub-domain will it solve the issue or wordpress’s front controller will pickup any request related to that domain?
Is it possible at all? My suggestion would be appreciated.
many thanks,
Mahbub
It's absolutely possible, yes. And there are many scenarios you can use depending on what you want to do:
Subdomains — install everything in different subdomains, or install one thing at the root and the others in different subdomains. The subdomains normally just map into directories on the same account, so you use the same FTP credentials and so on to transfer files.
Directories — like http://www.example.com/blog. Very easy to deploy a blog this way, and just put your other stuff in the root.
Intermingling — you can actually put files (.php, .html, etc.) in the same directory as WordPress, just as long as there are no name conflicts. The default redirection rules in .htaccess will ensure that those files will get served as usual without interfering with WordPress.
Not knowing anything about your code, if it's simple enough another approach would be to create custom page templates in WordPress that invoke your code. The nice thing about this is that your pages will always have the same look and feel as the other pages in the blog, i.e. if you change/update the theme. This may or may not matter to you.
Its possible. We have implemented it for multiple sites in the following ways
Elgg as Master
FluxBB / PhpBB for forum
Wordpress for blogs
You can then share the sessions between these systems. Just process your login/ registration through only one system.
Sure, you can set the wordpress site in for example: http://blog.example.com and the website in http://www.example.com without any problem. Just need to setup that in the web server.
I did it by putting the wordpress blog in a separate directory inside the large domain. wordpress do not interfere with other php sites on the same domain.
Yes, it's possible.
We'd used Drupal for main website, ELGG for social networking, PHPBB3 for forums and Wordpress for blogging on the same domain name. We did it by using different subdomains for each site.
Suddenly, my images are not showing up on my site when accessing https pages. No change in my code. My host did have to recompile their ftp service with SSL support after my request (so I could ftpes my site). Can't thing of anything else that would affect my SSL cert. Same thing happens on FF and IE and on different computers.
If I go to your website ( https://www.scfootball.org/ ), I don't see the images, as you said : I get a 403 (Forbidden) error for each one of those -- I can see this using the "Net" tab of the Firefox extension Firebug, for instance.
If I try to see an image directly, without going trough the site (for instance : https://www.scfootball.org/widgets/GulloParkHeader.png ), then, I can see the image.
If you try, make sure you copy-paste the URL to a new tab/window, and not just click on it
Which means there is some kind of trouble between the website and the access to the images ; not on the images themselves.
If I disable the referer in firefox (the web developper toolbar extension allows that easily) and refresh your website's webpage, the images appear.
If I re-enable the referer, and refresh again, then the images don't appear anymore.
Which means there is something, related to the referer, that prevents the images from being sent, and returns a 403 error instead.
Just a wild guess : maybe there's a .htaccess in your widgets directory (or somewhere else) that prevents images from being served, if the referer doesn't correspond to a specific domain ?
Considering the images are displayed on the site when I access it without HTTPS (i.e. with an URL such as http://www.scfootball.org/index2.php ), maybe there is a "protection" in place so your images are not displayed if the Referer is not that non-https website... And that "protection" has not been updated when you switched to HTTPS ?
(I've seen that kind of "protection" used to prevent hot-linking of images, for instance)
This is an old post but, it could be hotlink protection too.
If you turn it on an allowed alias for a http:// domain you gotta for its https:// too, otherwise itll deny your images from being called to client.
I used DJango API to test locally, everything is normal, after deploying SSL, the interface access is normal, but the picture shows 404
Yeah, "not showing up" is a little vague. If the HTML is served by HTTPS and the images are still being served by HTTP, there's a little security leak inherent in the page, which your browser may deal with in one of several, largely ineffectual, ways.