Saving and Serving static index page in Wordpress - wordpress

i thought it was simple.. or i might have missed something.. i wanted to save the output of wget and serve it as the index page... but for some reason it always serve the php version instead of the html.
i thought of changing "DirectoryIndex" to serve index.html first.. and restarted apache..
now the issue is when i do wget www.mysite.com/index.php -O index.html it ways serve the HTML version even though i specified index.php
maybe its wordpress related or some misconfig that i did..
tia,

Not sure I understand what you mean. :/
Do you want to use wget to fetch content from other website and serve it within WP?
----- Some type of cache -----
You have to call wget using directly the URl of your site, not index.php. For instance:
wget -O index.html http://yoursite.com
The you get your index.html with its content: css, text, images, js... You might use a redirection rule to serve such file as the default page.

Related

serve assets file with invaid names with nginx

I have download a full wordpress website with below command:
wget -r --convert-links --no-parent website_url
I want to server this site with nginx but there is a problem.
some of files has an invalid names with version like js_composer_front.min.js?ver=6.0.5 and nginx throw 404.
how can I solve this problem?
As far as I know, you can't fix the mentioned issue with Nginx and Wget, you should write script to modify generated links, maybe sed or python script.
I think the better solution is to use simply-static plugin.

What happens if no mime.types is included in nginx.conf?

I have a custom nginx.conf file that I start nginx with using the cli, for example nginx -c /my/path/nginx.conf.
I have found that if I take the include /my/path/mime.types from the custom nginx.conf file, that the server still starts up fine, and webpages seem to load normally with no apparent errors.
I have been researching nginx directive priority, but I cannot see any reason that the default mime.types might be getting included. Is it safe to remove the custom mime.types include?
(I should clarify that there is nothing special about the contents of /my/path/mime.types. For the purposes of this question, consider it to be effectively the same as the contents of the default file.)
Actually i did some tests and concluded that if you comment out the mime.types line in the /etc/nginx/nginx.conf file
# include /etc/nginx/mime.types
And restart nginx
sudo service nginx restart
And you clear the browser cache before accessing again your page, you will notice that nginx will not take advantage of mime.types configuration (of course), and will NOT render correctly the media type of your content.
The following example, shows how styles.css is rendered (Content-Type: application/octet-stream) instead of text/css
To sum up, yes mime.types is required for nginx to render the right media type of content.

Docker/nginx [windows10] - change page on linked folder and show changes directly in the browser

Question: How can I change the index.html file in docker/nginx and see the changed results in my browser?
The index.html is on a private folder linked to the standard nginx folder.
What did I do:
After installing docker and nginx via the official pages, I created a folder under /Users/me123/docker/webapp/html. In this folder I created an index.html file.
I linked this folder to the default nginx folder via the following command. I used both the RO and not-RO versions:
docker run --name nginx -p 80:80 -v //c/Users/me123/docker/webapp/html:/usr/share/nginx/html -d nginx
So, when editing the file (with e.g. Notepad++) I expected to see the updates. Alas, even in firefox with ctrl-F5 or control-refresh-icon. So, this is really not a caching problem. I visited the page via 192.n.n.n/index.html.
When I delete the index.html file, then I got an error. When I put the index.html file back I see the old index.html content.
I saw a post that this may be due to inode-synchronisation/updates. So a 'docker restart nginx' would be sufficient. Alas. Even the sequence 'docker stop nginx' and 'docker rm nginx-package-via-number' won't help.
When I add a new file to my local /Users/me123/docker/webapp/html folder, I immediately see the contents.
So, how can I change the index.html file and see the changed results in my browser?
I tried to add tags in my index.html to prohibit caching - alas.
The solution is by changing the nginx.conf file.
Use the following and the problem is solved:
sendfile off;
By default it is set on.

solution for wrong links via mod rewrite?

Hi and thanks for reading my question.
Its my first so please be gentle as im not a programmer but a barge captain, and curious ))
The situation:
I run a small website and we want to serve more languages, the website is based on Wordpress multisite.
After trying various translation solution we decided to go with transposh.
That plugin enables us to translate content easily and it becomes available at domain.com/en domain.com/fr etcetera those directory´s are virtual.
As we have different domain names for different languages i needed a solution to have the content of domain.com/en on domain2.com
What i did was to set the cache directory (static html) of domain.com as webroot of domain2.com. A fairly simple solution and it works like a charm.
The only problem i face is that the menu items link back to the domain.com and not domain2.com
I tried to make urls relative via wp core and two plugins but as the trailing /en or /fr is virtual making the urls relative just links back to domain.com
I have spend two days googling and im realy out of ideas. I tried different php script for search and replace, cgi scripts, perl scripts but none seem to do the job. I dont have shell access.
I was wondering if its posible to do smth like that with mod rewrite and if posible then how?
simply put:
static html site with wrong links
can i change the links via htaccess or other method which is easy (relatively) to understand and maintain?
The cache gets rebuild now and then of course
This is solved by an other approach:
Instead of using the cache i creatd a cronjob with wget:
/usr/bin/wget -np -P /destination-eg-yourwebroot/ --html-extension -nH -p -k -r http://domain.com
This creates a html copy of your website in the webroot of the new domain
For some reason wget does not always update the links in the copy, so they will point to original domain
We can run the command again but then prepend it with /usr/bin/wget -nc -k
/usr/bin/wget -nc -k -np -P /destination-eg-yourwebroot/ --html-extension -nH -p -k -r http://domain.com
It will update the links correctly, including css urls
U now have a clean copy of your website on a different domain

What are all of Wordpress' public/direct entry-points?

I realize this is a bit of a strange question, but to put a long story short, we have a few Wordpress installs whose files are loaded through a symbolic link (the symlink is in the document root whereas Wordpress is not).
For this to work, I need to have a list of all Wordpress files that are usually loaded directly from the web browser (either by the user or through AJAX), such as: index.php, wp-login.php, (all theme files)* ...
An example of files that are not loaded directly: wp-load.php, wp-config.php, wp-blog-header.php...
[*] Theme files are an exception; they actually exist in the document root.
Edit: You might wonder, what is the point of this? It is so that we can cut down on the extra files on the server; it's useless to have thousands of identical files from each Wordpress website. The wp-content directory has been left there since it's what changes between websites. Am I aware of the consequences of such a set up? I believe I am.
Edit 2:
http://codex.wordpress.org/WordPress_Files
Here is a list of entry points based on require( 'wp-load.php' );
https://github.com/szepeviktor/WPHW/blob/master/wp-entry-points.md
And a Trac ticket about their deficiencies
https://core.trac.wordpress.org/ticket/28364
So far, the following fixes my issue:
ln -s /var/www/vhosts/mainsite/httpdocs/index.php /var/www/vhosts/subsite/httpdocs/index.php
ln -s /var/www/vhosts/mainsite/httpdocs/wp-login.php /var/www/vhosts/subsite/httpdocs/wp-login.php
ln -s /var/www/vhosts/mainsite/httpdocs/wp-admin /var/www/vhosts/subsite/httpdocs/wp-admin
ln -s /var/www/vhosts/mainsite/httpdocs/wp-includes /var/www/vhosts/subsite/httpdocs/wp-includes

Resources