-
- Always look for the official documentation, this tutorial may not suit you as there are new updates to the installation process.
- References are at the end of the document.
$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '" | |
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'; | |
if( $found ){ | |
$remoteport = $matches[0]; | |
} else{ | |
echo "The Script Exited, the ip address of WSL 2 cannot be found"; | |
exit; | |
} |
<ruleset name="PHP_Codeer" xsi:noNamespaceSchemaLocation="phpcs.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> | |
<description>The coding standard for PHP_Codeer itself.</description> | |
<!-- Files --> | |
<file>bin</file> | |
<file>src</file> | |
<!-- Excludes --> | |
<exclude-pattern>vendor/</exclude-pattern> |
alias pushlock='COMPOSER_DISCARD_CHANGES=stash composer update --no-interaction && git add composer.lock && git commit -m "[UPDATE] composer.lock" && git push' |
Hosting multiple websites on a single public IP address on the standard HTTP(S) ports is relatively easy with popular web servers like Apache, Nginx and lighttpd all supporting Virtual Hosts.
For Web Services which bundle their own HTTP server, things get more complicated, unless their HTTP stack can be shared somehow. More often than not, the application's HTTP stack listens directly on a dedicated TCP port.
Hosting multiple services on a single IP then requires using a fronting server listening on the standard HTTP port, and routing to the right backend service based on the host name or the path sent by the client.
Path based routing is cumbersome, usually requiring either the service to be aware of the path prefix, or a rewrite by the HTTP fronting server of all absolute URLs in the requests and responses.
Hostname based routing is more straightforward. The fronting server can just look at the [HTTP/1.1 Host header](https://tools
<?php header('Content-Type: text/html; charset=utf-8'); ?> | |
<html> | |
<head> | |
<title>Fix wrong encoded UTF8 characters</title> | |
<meta http-equiv="Content-type" content="text/html; charset=utf-8" /> | |
</head> | |
<body> | |
<pre> | |
<?php | |
/* Problem description: |
# [<tag>] (If applied, this commit will...) <subject> (Max 72 char) | |
# |<---- Preferably using up to 50 chars --->|<------------------->| | |
# Example: | |
# [feat] Implement automated commit messages | |
# (Optional) Explain why this change is being made | |
# |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
# (Optional) Provide links or keys to any relevant tickets, articles or other resources | |
# Example: Github issue #23 |
Short (72 chars or less) summary
More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages