autotutorial

Disable Directorylisting https://www.thesitewizard.com/apache/prevent-directory-listing-htaccess.shtml
Enable Directoryindex http://www.htaccess-guide.com/directoryindex-uses/
Currently you cannot use files, folders that actually exists outside the context of WordPress, you have to delete the existing folder or file and WordPress when it is not a regular file or it is not a directory thinks it is a slug of the path.

To connect to the server following data directory initialization, you must therefore use a client or connector that supports caching_sha2_password. If you can do this but prefer that the not_user_root account use mysql_native_password after installation, install MySQL and initialize the data directory as you normally would. Then connect to the server as root and use ALTER USER as follows to change the account authentication plugin and password:

ALTER USER 'not_user_root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'password';

If the client or connector that you use does not yet support caching_sha2_password, you can use a modified data directory-initialization procedure that associates the not_user_root account with mysql_native_password as soon as the account is created. To do so, use either of these techniques:

Supply a –default-authentication-plugin=mysql_native_password option along with –initialize or –initialize-insecure.

Set default_authentication_plugin to mysql_native_password in an option file, and name that option file using a –defaults-file option along with –initialize or –initialize-insecure. (In this case, if you continue to use that option file for subsequent server startups, new accounts will be created with mysql_native_password rather than caching_sha2_password unless you remove the default_authentication_plugin setting from the option file.)

https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password

(WordPress 5.3 have support for php 7.4) From php 7.4 MYSQL Native Driver (MYSQLND) there should be support for the connector, also with caching_sha2_password
https://github.com/php/php-src/commit/4f06e67ad2201390ed35a9ea6288a00c0b04782b#commitcomment-32356655

For plug-in PAM https://wordpress.org/support/topic/mariadb-authentication-does-not-work-when-mariadb-is-integrated-with-pamldap/

• This reply was modified 6 years, 4 months ago by autotutorial.

the path of the attachments is stored in your database (the actual content resides in the uploads directory), then be seen in the multimedia library.
Enable debugging I hope this helps.
Do not hesitate to write in case of problems.
https://wordpress.org/support/topic/no-results-in-media-search/
some configurations require 775 from the parent folder to the daughter folder and 664 files.
But if you set 777 from the parent folder to the 777 daughter and file folder and it appears in the media library, it means you have permission issues (owner of the file, wrong permissions or both).
Setting to 777 is only useful for debugging, leaving this forever exposes you to security risks.
install the healt check plugin and in troubleshooting view file system permissions … it should say writable uploads folder.

Rewrite url for nginnx https://wordpress.org/support/article/nginx/
Your installation is currently in the astronomia directory.

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /astronomia/
RewriteRule ^astronomia/(index\.php)?$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /astronomia/index.php [L]
#RewriteRule ^(.+)$ /astronomia/index.php/$1 [L,QSA]
#RewriteRule !^addnew/ addnew%{REQUEST_URI}
</IfModule>

# END WordPress

Sorry
replace $localtime = $var->getTimestamp()+$var->getOffset(); with $localtime = $var->getTimestamp() 23:00 UTC it’s correct, use timezone for consversion Europe/Rome 00:00 🙂 (convert local to UTC with this timezone $object->setTimezone( new DateTimeZone( 'UTC' ) ); ).

$array = current_datetime();
$var = $array->setTime( 0, 0, 0, 0); // Work for version PHP 7.1 or above

$timestamp = $var->getTimestamp();
$my_date = new DateTime( '@' . $timestamp );
$my_date->setTimezone( new DateTimeZone( 'UTC' ) ); //23:00 UTC correct

//local time
$timezone = $var->getTimezone(); //Europe/Rome offset +01:00
$my_date2 = new DateTime( '@' . $timestamp );
$my_date2->setTimezone( $timezone ); //00:00 Europe/Rome correct

//Local time show UTC, never use it
$new_timestamp = $timestamp+$var->getOffset();
$my_date3 = new DateTime( '@' . $new_timestamp )
$my_date3->setTimezone( new DateTimeZone( 'UTC' ) ); //00:00 correct conversion from local to UTC

https://www.php.net/manual/en/function.date-default-timezone-set.php
date-default-timezone-set and https://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone date.timezone
I can set a time zone, WordPress for over 10 years has been using default UTC, you can later select your time zone (timezone string or offset number) in the dashboard, the old php functions if they have a timezone other than UTC they produce a timestamp for that timezone while $array->getTimestamp() is the from UTC.
Since you use an explicit timezone in DateTime your local time is always the correct one, it should also be remembered that Europe/Rome 2020-03-29 02:00:00 with the time zone Europe/Rome shows 2020-03-29 03:00: 00 Daylight saving time is in use (the timestamp is always UTC, the output for Daylight saving time changes).
since current_time before WordPress 5.3 calculated a WP offset (he took UTC for granted and did the sum with the offset in the dashboard).
As of WordPress 5.3 it is safe (now WordPress use DateTime class).
Since in the past it has been used incorrectly it is right to remove current_time and use current_datetime.

in normal conditions the temporary folder should delete the files at the end of the code (for this reason a temporary folder is used otherwise the problem lies in the server but WordPress should understand if you have such a defect), what error does it tell you?