autotutorial

Il Multisito usa la riscrittura della url, htaccess per apache o riscrittura per Ningx e altri server.

Devi contattare entrambi i supporti dei due plug-in (possibilmente gp-premium ha un modulo per polylang… Quindi il problema potrebbe crearlo lui)
Supporto in lingua inglese Gp-Premium https://generatepress.com/support/
Supporto in lingua inglese Polylang https://wordpress.org/support/plugin/polylang/
Il supporto Server to Server del tuo hosting é un modo per dire "abilitare la connessione esterna (internet)"
Se disattivi il plugin gp-premium e tieni attivo polylang il problema scompare? Se é si ( il problema é causato al 100% dal plugin Gp-Premium e non avere questa patch https://bugs.php.net/bug.php?id=62577 libxml_disable_entity_loader(true);
)

Attualmente stai utilizzando i permalink Ugly devi selezionare altro e WordPress tenterà di creare un file .htaccess nella root del tuo sito.
Le tue immagini risiedono fisicamente nella cartella /wp-content/uploads/ANNO/MESE/ puoi controllare se esiste qualche file o addirittura se esistono le cartelle anno mese?
Tieni presente che con i caratteri accentati nel percorso dei file sarà assai difficile se un domani ti sposti su un server windows.. Usa solo dalla a-z.
Altresi puoi configurare la costante WP_CONTENT_DIR per accedere in nome diverso da wp-content. Anche per la cartella uploads esiste una costante.

• Questa risposta è stata modificata 4 anni, 10 mesi fa da autotutorial.

site_url visualizzazione sito mentre home_url si riferisce ai file di dove risiedono (il core, suppongo anche i caricament e i post).
Siccome lavori con plug-in a pagamento devi essere sicuro (nonché tuo diritto) su come effettua questi cambiamenti.
Normalmente esistono due metodi, uno che modifica .htaccess e l’altro site_url cito i passaggi 7,8,9,10,11.
7 della guida seguente “COPIA NON SPOSTA” dalla directory di WordPress nella directory principale del tuo sito (visualizzazione sito).
8 apri la tua directory root index.php
9 modifica require( dirname( __FILE__ ) . '/wp-blog-header.php' ) in require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' ).
10 fai il login
11 clicca su save i permalink.
*Nota la guida fa riferimento a un spostamento su una cartella wordpress /wordpress/wp-blog-heder.php sarà inserito nel file root (poiché site_url é impostato nella root e home_url spostato nella cartella wordpress “quasi” come nel tuo caso).

https://wordpress.org/support/article/giving-wordpress-its-own-directory/
Detto questo significa che i plug-in da te utilizzati fanno questo cambiamento (se rispecchiano il core WordPress, in tanti elaborano i propri codici php ma difficilmente sono basati sul tutto il core WordPress).

Puoi postare il tuo file .htaccess senza htpassword o comunque senza informazioni personali, il require della root per il file index.php?
Mi dispiace WordPress non definisce chiaramente cosa sia site_url , a limite ti crei un plugin e usi la funzione per recuperare il site_url e se non ti piace fai un redirect.

Questo é un argomento avanzato e ti può rispondere solo chi sviluppa con WordPress.

È anche il mio dubbio poiché non conosco cosa é idoneo per WordPress url e cosa per Site url.
Altrimenti sarebbe facile stilare una regola htaccess.

Dunque il site_url (Site Adress) è l’indirizzo che vuoi che le persone digitino nel loro browser per raggiungere il tuo blog WordPress.
Però inizialmente avevi un percorso diverso e nel caso di installazione singole WordPress devi modificare i vecchi percorsi in quelli nuovi mentre se usi WordPress multisite devi modificare wp_options, wp_options2 wp_site e altro come spiega il link di seguito, forse wp_options avrà già il tuo site_url corretto (poiché é stato impostato da te) però non so se i vecchi: post, file caricati potrebbero avere la vecchia url quindi crea un nuovo: post e carica una nuova immagine se il post é senza la cartella web dovrai modificare le voci che si riferiscono a site_url e se la cartella uploads é comprensiva di web/ allora non dovrà essere modificata https://wordpress.org/support/article/changing-the-site-url/#changing-the-url-directly-in-the-database

Prima di qualsiasi operazione crea un back-up dei file e del database, non fare altri tentativi eccetto la modifica al database ma con plug-in (i temi, widget, plugin potrebbero serializzare i percorsi quindi manualmente é una cattiva pratica).

Qui una lista di possibili opzioni per modificare il database https://wordpress.org/support/article/moving-wordpress/#changing-your-domain-name-and-urls
*Ricorda devi modificare solo wp_site, wp_options unicamente per site_url nella maggior parte dei casi, se un plugin non indica cosa stai per cambiare non fare nulla piuttosto resta così.
Scusami non esiste una guida chiara per quando c’è solo site_url a essere diverso ma con i doppi tentativi (provando e controllando il percorso di post e upload sarai certo di quale percorso é obbligatorio).

Per i tuoi usi futuri imposta sin dall’inizio senza web nel percorso site_url, se ancora da browser vedrai un 404 o accedere alla cartella web quando il percorso iniziale é privo di web si dovrà procedere con una riscrittura url (htaccess o plugin redirection e similari) ad esempio /web/wp-admin/ sarà un percorso sempre valido (si dovrebbe stilare una lista quando la cartella web é legittima per il contensto WordPress url e ciò ne consegue che tutto il resto sarà valutato per il contesto Site url).

Perdonatemi ho fornito un codice errato.
dopo il define

$incauto = 0;
$autoabs[0] = ABSPATH;
++$incauto;
$autoabs[] = $incauto;

nell’else

$autoabs[] = ABSPATH;
function var_x_error_log( $objectauto=null ){
ob_start(); // start buffer capture
var_dump( $objectauto ); // dump the value
$contentsauto = ob_get_contents(); // put the buffer into a variable
ob_end_clean(); // end capture
error_log( $contentsauto."\n",3,dirname(__FILE__).'/test.log'); // log contents of the result of var_dump( $objectauto )
return $contentsauto;
}
var_x_error_log( $autoabs );

Dovrebbe creare un test.log con tre array il primo é la referenza di ABSPATH dopo il define, il secondo incrementa una variabile (dovrebbe sempre essere a 1 il suo valore e chiave), il terzo é la referenza ABSPATH prima di tentare l’installazione e la chiave dovrebbe sempre essere a 2.

Siccome da php 7.2 non esiste più mcrypt hanno deciso di utilizzare libsodium (libreria di default php 7.2) altrimenti WordPress utilizza sodium_compact (libreria da terzi che consiglia qualsiasi sistema a 64 bit).
Lentezza solo per il secondo metodo sodium_compact: (soprattutto per php 5 su windows) Questo vale anche per i sistemi operativi non Windows a 32 bit, o se in qualche modo PHP è stato compilato dove PHP_INT_SIZE equivale a 4 al posto di 8 (cioè Linux su i386).

Il discorso ovviamente é riferito per la verifica della firma (aggiornamenti automatici, plugin, temi ecc.).
Prego @luca21
https://github.com/paragonie/sodium_compat/blob/master/README.md

Quando il tuo sito WordPress installa un aggiornamento automatico, dalla versione 5.2 in poi controllerà innanzitutto l’esistenza di x-content-signature un’intestazione. Se uno non viene fornito dal nostro server di aggiornamento, il tuo sito WordPress cercherà invece un filenamehere.sig file e lo analizzerà.
Secondo questa affermazione é già attivo anche per plugin, temi ecc.