Mappen, bestanden & rechten - 2020 (WordPress, 2): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
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.
  
== Nieuwe oplossing: Verruimde schrijfrechten ==
+
== 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"

Zie ook