Nefunkční administrace po nastavení přátelských url

Ahoj všem,

postupně převádím weby na J!4 a narazil jsem na jednu nemilou věc, jejíž řešení se mi nedaří najít ani tady ve fóru ani nikde vygooglit. Protože na jeden web potřebuji mít zaheslovaný přístup (ale z mnoha důvodů si nemohu dovolit používat ACL s J!), tak nastavuji .htaccess a .htpasswd. Jakmile ovšem v J!4 nastavím přátelské URL a přenastavím htaccess.txt na .htaccess, tak mi z administrace zmizí celé css a žádná úprava v administraci nejde uložit, protože tlačítka nejsou aktivní (kromě css se zřejmě nenačte ani js). Nevíte, prosím, někdo, zda to jde nějak vyřešit (nebo alespoň vrátit zpátky). Nepřišel jsem na to, kterou položku v configuration.php změnit, aby to zpátky načítalo htaccess.txt a tím pádem fungovala administrace.

Jediné, co se mi podařilo najít, tak je popis tohoto problému už od počátku J!4, ale bohužel jsem nikde nedohledal žádné řešení.

Díky moc za pomoc či nasměrování (případně alespoň radu, jak to vrátit zpátky do funkčního modelu bez .htaccess).
 

Tak návrat do původního stavu jsem již vyřešil. Pokud by to někdo potřeboval, tak stačí položku $sef_rewrite přepsat z true na false.

To bohužel ale neřeší můj původní problém - jak zprovoznit .htaccess s .htpasswd na J!4.

Tak jsem zkoušel trochu pátrat dále a přišel jsem na následující:

• .htaccess a .htapasswd funguje pro celý web ve všech variantách, problém je jen ve fungování administrace (.htpasswd potřebuji primárně pro frontend, backend lze zabezpečit např. i přes dvoufaktorové přihlášení)
• když v Globálním nastavení zapnu Kompresi GZIP, tak se administrace načte v plné grafice, ale bohužel stále bez funkčních tlačítek
• takže ještě někde něco blokuje .js (asi nějaká obdoba GZIPu, který blokoval .css)
• pokud na webu nechám jen výchozí htaccess.txt, tak vše funguje i bez zapnutí komprese GZIP (ale bez možnosti použít .htpasswd)
• na stejném serveru mám i jiné weby na J!3 a tam .htaccess s .htpasswd funguje bez problémů (i s vypnutou kompresí GZIP), s tímto jsem se zatím setkal jen u J!4
• Admin Tools je pro mé účely nadbytečně robustní řešení (jediné, co bych z něj použil je vygenerování .htaccess a .htpasswd a to je jen v placené verzi a otázkou je, zda by to vyřešilo daný problém nebo ne), .htaccess a .htpasswd nemám problém vytvořit sám, jen potřebuji rozlousknout, co blokuje načítání .css (pravděpodobně nepovolená komprese GZIP, i když to v J!3 nebylo potřeba) a .js (tam zatím netuším)

Osobně si myslím, že by to mělo jít nastavit bez jakýchkoliv dalších rozšíření i v čisté J!4 stejně jako to šlo v J!3.

Zajímavé je, že když odkomentuji RewriteBase, tak administrace nějakou dobu funguje, ale po několika kliknutí na Uložit a zavřít kdekoliv v administraci opět zmizí grafika i funkčnost tlačítek. Pokud do RewriteBase zadám adresu, která je v configuration.php, tak se mi rozsype i frontend a na všechny odkazy generuje chybu 500, takže bez povoleného RewriteBase či jen s RewriteBase / je to asi správně. Dělá mi to jen v administraci (výchozí šablona Atum), frontend se chová s htaccess.txt i .htaccess stejně a tak jak má.

Tak jsem to testoval na čisté instalaci J!4 a v konzoli jsem zjistil, že je problém v tom, že se to snaží načíst css a js, které mají v názvu min (ve výchozím nastavení po čisté instalaci jde o následující soubory: core.min.js, template.min.js, login.min.js, keepalive.min.js, passwordview.min.js a messages.min.js). Kompresi GZIP mám vypnutou (výchozí nastavení čisté instalace), ale ani její zapnutí nemá žádný vliv na výsledek.

Uvedené soubory při pohledu přes FTP, ale na uvedených adresách existují. Jak mám přesvědčit J!4, aby je načetla? Jediné, co jsem doplnil při instalaci byla čeština, jinak je to čistá instalace s výchozí šablonou (Cassiopeia) bez jakýchkoliv rozšíření.

Tak mě napadlo ještě vyzkoušet .htaccess z jiného webu na stejném serveru (z instalace J!3, kde to funguje správně) a hle - vše funguje jak má. Takže zakopaný pes bude někde v tom přejmenovaném htaccess.txt přímo v J!. Až budu mít chvilku, tak zkusím porovnat, který příkaz je tam špatně a své zjištění hodím sem pro ostatní.

Jinak moc děkuji Bongovi, Conymu a Cufemu za nasměrování, kde hledat jádro problému.