Mappen, bestanden & rechten - 2020 (WordPress, 2): verschil tussen versies
Regel 21: | Regel 21: | ||
Ik heb het nog steeds niet goed geanalyseerd, maar WordFence doet nog altijd moeitlijk. | Ik heb het nog steeds niet goed geanalyseerd, maar WordFence doet nog altijd moeitlijk. | ||
− | == | + | == Oplossing: Verruimde schrijfrechten == |
De nieuw oplossing is hetzelfde als de [[Mappen, bestanden & rechten - 2020 (WordPress) | oude oplossing]], maar met meer plekken binnen een WordPress-installatie waar computeraccount <code>www-data</code> (gebruiker; Apache) mag schrijven. | De nieuw oplossing is hetzelfde als de [[Mappen, bestanden & rechten - 2020 (WordPress) | oude oplossing]], maar met meer plekken binnen een WordPress-installatie waar computeraccount <code>www-data</code> (gebruiker; Apache) mag schrijven. |
Versie van 28 aug 2020 11:13
Configureren van rechten op bestanden en mappen rondom een WordPress-installatie, kan best complex zijn. In mei 2020 dacht dat ik er uit was: WordPress mag basically geen bestanden overschrijven, en updates gaan volledig via eigen scripts.
Dat bracht echter een probleem met zich mee: Zonder schrijfrechten worden een aantal dingen toch wel erg ingewikkeld.
Problemen
Automatische theme-updates
We hebben een project waar een externe partij het theme ontwikkeld. Nieuwe theme-updates kunnen automatisch worden toegepast. Het is onhandig dat dat nu niet werkt
Cache legen
Het is onhandig dat cache-plugins niet zelf de cache kunnen lezen wegens gebrek aan schrijftoegang
W3 Total Cache-configuratie
Plugin W3 Total Cache Error wil tijdens installatie bepaalde mapen & bestanden schrijven of aanpassen. Dat kan nu niet. Handmatig wil dat ook niet zo gemakkelijk lukken, ook al geeft de plugin aan, wat er precies moet gebeuren
Altijd gedoe met WordFence
Ik heb het nog steeds niet goed geanalyseerd, maar WordFence doet nog altijd moeitlijk.
Oplossing: Verruimde schrijfrechten
De nieuw oplossing is hetzelfde als de oude oplossing, maar met meer plekken binnen een WordPress-installatie waar computeraccount www-data
(gebruiker; Apache) mag schrijven.
Dit is geen al te schokkende verandering: Apache kon uiteraard al schrijven in /wp-content/uploads
. In scripts ging dat met een regel zoals:
sudo chmod -Rv u+w $path"/wp-content/uploads"