Free software

The mainly difference, which help to decide the selecting decision for the software design is the embedded mode. H2 supports this kind of the mode while PostgreSQL doesn't support it. Further H2 is platform independent and mostly used for the small application and PostgreSQL only supports some kind of the OS.

The easiest way to get to the desktop version of a website is by selecting the desktop view link on the page itself - if it is provieded! Not every website has this option, so of course your described methods are usefull in this cases as a quick workaround.

Taggings:

It should be stated, that when Adblocker is installed, it will block also the content of some websites. But it is still possible to prevent sites from detecting the usage of an Adblocker.

Taggings:

On Mozilla Firefox, you can also do this by opening the menu to the right(three dots on top of each other) and checking "request desktop site". Requesting desktop is particularly useful for youtube videos of songs, because this way, you can lock your mobile device and still listen to the song, which is not possible through the youtube app.

Technology:

The problem can be solved by using a Nginx reverse proxy. Each application will be exposed through a corresponding sub-domain.

Dockerfile:

FROM nginx:alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY proxy.conf /etc/nginx/includes/proxy.conf

proxy.conf:

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_request_buffering off;
proxy_http_version 1.1;
proxy_intercept_errors off;

nginx.conf:

# pm config.
server {
listen 80;
server_name site1.myproject.com;
location / {
include /etc/nginx/includes/proxy.conf;
proxy_pass http://site1_webserver_1;
}
access_log off;
error_log /var/log/nginx/error.log error;
}
# api config.
server {
listen 80;
server_name site1.myproject.com;
location / {
include /etc/nginx/includes/proxy.conf;
proxy_pass http://site2_webserver_1;
}
access_log off;
error_log /var/log/nginx/error.log error;
}
# Default
server {
listen 80 default_server;
server_name _;
root /var/www/html;
charset UTF-8;
access_log off;
log_not_found off;
error_log /var/log/nginx/error.log error;
}

The proxy_pass is the name of the application's docker container.

Technology:

I will explain a solution for the popular Open-Source tool Filezilla. Other FTP tools might handle charset encoding differently.

FileZilla offers three different charset settings:

  1. Autodetect
  2. Force UTF-8
  3. Use custom charset

Per default, FileZilla tries to detect the correct charset on its own. If this doesn’t work and your server uses some custom charset encoding, you need to set it via the Site Manager. In the tab “Charset”, a custom charset encoding can be specified for each individual server. Once it’s set, the specified charset encoding will be used for all future connections to this server and the filenames will be correct.

First, the Site Address and the WordPress address need to be updated. Go to Settings->General in the WordPress administration area and change the value of these two settings to the new URL. New contents are now created with HTTPS.

Unfortunately, changing the site address does not update URLs in existing contents, so a SQL-Statement to replace the old URLs with new one is required (replace example.org with the URL of the site to move):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://www.example.org', 'https:// www.example.org)

Subscribe to Free software