Notepad++ saves these temporary files for only a certain amount of time, so there's no guarantee that you will be able to recover your lost tab, specially if it was closed too long before. But it's still worth a shot to avoid losing work.
- Go to
console %APPDATA%\Notepad++\backups
git checkout -b master | |
git log -1 | |
# commit 65345471c1040ceb90b1817d7427d58d7b09fdca (HEAD -> master) | |
git checkout -b develop | |
git log -1 | |
# both branches are at the same ref: | |
# commit 65345471c1040ceb90b1817d7427d58d7b09fdca (HEAD -> develop, master) | |
echo "a feature" > feature.txt |
#!/bin/bash | |
# Put this file at: .git/hooks/post-checkout | |
# and make it executable | |
# You can install it system wide too, see http://stackoverflow.com/a/2293578/685587 | |
PREV_COMMIT=$1 | |
POST_COMMIT=$2 | |
NOCOLOR='\e[0m' |
<?php | |
// -- types are a compile-time propagated concept | |
// https://psalm.dev/r/338f74a96c | |
class TheType | |
{ | |
/** @var string */ | |
public $foo = 'bar'; | |
} |
Magento 2.3.7 and 2.4.2 ship with composer v2 support out of the box but as far as I can see the only thing that needs to happen is to use some more modern versions of certain composer plugins which are used by certain dependencies of Magento.
This means we should be able to add composer v2 support to older Magento2 versions as well if we get a bit creative.
See below for diffs of the composer.json
files you can apply to your projects, be sure to keep a mental note of these things, they will need to maintained by yourself in case newer versions of these modules are released. And if one day you update to Magento 2.3.7 or 2.4.2 or higher, you can remove these changes again.
default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
# A number of these changes come form the following PR's; , combines changes in https://github.com/magento/magento2/pull/29360, https://github.com/magento/magento2/pull/28944 and https://github.com/magento/magento2/pull/28894, https://github.com/magento/magento2/pull/35228, https://github.com/magento/magento2/pull/36524, https://github.com/magento/magento2/pull/34323 | |
# VCL version 5.0 is not supported so it should be 4.0 even though actually used Varnish version is 6 | |
vcl 4.1; | |
import std; | |
# The minimal Varnish version is 6.0 | |
# For SSL offloading, pass the following header in your proxy server or load balancer: '/* {{ ssl_offloaded_header }} */: https' | |
backend default { | |
.host = "/* {{ host }} */"; |
- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123
- search - The stuff after
?
in a URL like/assignments?showGrades=1
. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#
portion of the URL. This is not available to servers inrequest.url
so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like
Because Varnish doesn't support SSL, most people choose a setup where Nginx SSL will forward all traffic to Varnish and Varnish will forward will forward the traffic it cannot handle back to nginx. Or worse, bind Varnish on port 80 and direct all traffic into Varnish. This will already degrade performance, because Varnish will purge more because static files are also taking up room in the cache.
Next up, the Nginx configuration of Magento will handle static files.