Ik heb een WordPress-blog geïnstalleerd in mijn lokale systeem. Maar wanneer ik plug-ins van admin probeer toe te voegen, vraagt het om FTP-toegang. Wat moet ik configureren om WordPress te laten uploaden zonder FTP?
Antwoord 1, autoriteit 100%
Probeer de code toe te voegen in wp-config.php:
define('FS_METHOD', 'direct');
Antwoord 2, autoriteit 14%
Als u Ubuntu gebruikt.
sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
Antwoord 3, autoriteit 8%
“Telkens wanneer u het WordPress-configuratiescherm gebruikt om plug-ins automatisch te installeren, upgraden of verwijderen, moet WordPress wijzigingen aanbrengen in bestanden op het bestandssysteem.
Alvorens wijzigingen aan te brengen, controleert WordPress eerst of het al dan niet toegang heeft om het bestandssysteem rechtstreeks te manipuleren.
Als WordPress niet de benodigde machtigingen heeft om het bestandssysteem rechtstreeks te wijzigen, wordt u om FTP-referenties gevraagd, zodat WordPress kan proberen te doen wat het moet doen via FTP.”
Oplossing:
Om erachter te komen als welke gebruiker uw apache-instantie wordt uitgevoerd, maakt u een testscript met de volgende inhoud:
<?php echo(exec("whoami")); ?>
Voor mij was het daemon en niet www-data. Corrigeer vervolgens de toestemming door:
sudo chown -R daemon /path/to/your/local/www/folder
Antwoord 4, autoriteit 4%
Ik heb het eigendom van de wordpress-map recursief gewijzigd in www-data en heb apache opnieuw opgestart.
sudo chown -R www-data:www-data <folderpath>
Het werkte als een tierelier!
Antwoord 5, autoriteit 3%
Op OSX gebruikte ik het volgende, en het werkte:
sudo chown -R _www:_www {path to wordpress folder}
_www is de gebruiker onder wie PHP draait op de Mac.
(Misschien moet u ook enkele mappen chmodden. Ik had dat eerst gedaan en het loste het niet op. Pas toen ik het chown-commando deed, werkte het, dus ik weet niet zeker of het zo was het chown-commando alleen, of een combinatie van chmod en chown.)
Antwoord 6, autoriteit 2%
WordPress vraagt om uw FTP-gegevens wanneer het geen toegang heeft tot de bestanden
direct. Dit wordt meestal veroorzaakt doordat PHP wordt uitgevoerd als de apache-gebruiker
(mod_php of CGI) in plaats van de gebruiker die eigenaar is van je WordPress-bestanden.
Dit is vrij normaal in de meeste shared hosting-omgevingen – de bestanden worden opgeslagen als de gebruiker en Apache wordt uitgevoerd als gebruiker apacheof httpd. Dit is eigenlijk een goede veiligheidsmaatregel, dus exploits en hacks kunnen gehoste bestanden niet wijzigen. Je zou dit kunnen omzeilen door alle WP-bestanden in te stellen op 777-beveiliging, maar dat betekent geenbeveiliging, dus dat zou ik ten zeerste afraden. Gebruik gewoon FTP, het is niet voor niets de automatisch geadviseerde oplossing.
Antwoord 7, autoriteit 2%
Ik heb WordPress lokaal geïnstalleerd op Ubuntu 14.04 volgens de stappen die hieren gewoon rennen:
sudo chown -R www-data:www-data {path_to_your_project_directory}
mijn probleem met het downloaden van plug-ins is opgelost. De enige reden waarom ik dit bericht hier laat, is omdat toen ik mijn probleem googelde, dit een van de eerste resultaten was en het me naar de oplossing voor mijn probleem leidde.
Hopelijk helpt deze voor iedereen!
Antwoord 8, autoriteit 2%
Als WordPress tijdens de installatie van een plug-in om uw hostnaam of FTP-gegevens vraagt.
Volg dan deze stappen:
Log in op uw server en navigeer naar /var/www/html/wordpress/.
Open wp-config.php en voeg deze regel toe na define(‘DB_COLLATE’)
define('FS_METHOD', 'direct');
Als u de foutmelding “Kan map niet maken” krijgt. Geef recursief schrijfrechten aan uw wordpress-map als
chmod -R go+w wordpress
OPMERKING. Trek om veiligheidsredenen deze machtigingen in zodra u een plug-in installeert als
chmod -R go-w wordpress
Antwoord 9
Ga eerst naar uw installatiemap (bijvoorbeeld)
cd /Applications/XAMPP/xamppfiles/
Nu gaan we uw htdocs-map wijzigen:
sudo chown -R daemon htdocs
Voer je root-wachtwoord in wanneer daarom wordt gevraagd en sluit het af met een chmod-aanroep:
sudo chmod -R g+w htdocs
Antwoord 10
De eenvoudigste manier om dit probleem op te lossen, is door de volgende FTP-informatie toe te voegen aan uw wp-config.php
define('FS_METHOD', 'direct');
define('FTP_BASE', '/usr/home/username/public_html/my-site.example.com/wordpress/');
define('FTP_CONTENT_DIR', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/plugins/');
FTP_BASEis het volledige pad naar de map “base” (ABSPATH) van de WordPress-installatie
FTP_CONTENT_DIRis het volledige pad naar de map wp-content van de WordPress-installatie.
FTP_PLUGIN_DIRis het volledige pad naar de map met plug-ins van de WordPress-installatie.
Antwoord 11
We hadden hetzelfde probleem als onderdeel van een groter probleem. De voorgestelde oplossing van
define('FS_METHOD', 'direct');
verbergt dat venster, maar toen hadden we nog steeds problemen met het laden van thema’s en upgrades enz. Het heeft te maken met machtigingen, maar in ons geval hebben we het probleem opgelost door van php OS-leverancier mod_phpnaar het veiligere FastCGI-toepassing van de php OS-leverancier.
Antwoord 12
Er zijn veel vergelijkbare antwoorden op deze vraag, maar geen van hen raakt de hoofdoorzaak volledig. Sebastian Schmid’scommentaar op het originele bericht raakt het, maar niet volledig. Dit is mijn mening vanaf 2018-11-06:
Hoofdoorzaak
Wanneer u een plug-in probeert te uploaden via de WordPress-beheerdersinterface, zal WordPress een aanroep doen naar een functie genaamd “get_filesystem_method()” (ref: /wp-admin/includes/file.php:1549). Deze routine zal proberen een bestand naar de betreffende locatie te schrijven (in dit geval de plugin-directory). Het kan hier natuurlijk onmiddellijk mislukken als de bestandsrechten niet goed zijn ingesteld om de WordPress-gebruiker (denk aan de gebruikersidentiteit die de php uitvoert) het bestand naar de betreffende locatie te schrijven.
Als het bestand kan worden gemaakt, detecteert deze functie vervolgens de bestandseigenaar van het tijdelijke bestand, samen met de bestandseigenaar van het huidige bestand van de functie (ref: /wp-admin/includes/file.php:1572) en vergelijkt de twee. Als ze overeenkomen, in de woorden van WordPress: “WordPress maakt bestanden aan met dezelfde eigenaar als de WordPress-bestanden, dit betekent dat het veilig is om bestanden aan te passen en nieuwe te maken via PHP” en wordt uw plug-in succesvol geüpload zonder de prompt voor FTP-referenties. Als ze niet overeenkomen, krijg je de prompt FTP-referenties.
Oplossingen
- Zorg ervoor dat de map met plug-ins kan worden geschreven door de identiteit die uw php-proces uitvoert.
-
Zorg ervoor dat de identiteit die uw php-proces uitvoert de bestandseigenaar is voor:
a) Alle WordPress-toepassingsbestanden, of…
b) Op zijn minst het /wp-admin/includes/file.php bestand
Laatste opmerkingen
Ik ben niet zo enthousiast over het specifiek toepassen van bestandseigendom op file.php om dit probleem te omzeilen (het voelt op zijn zachtst gezegd een beetje hacky aan!). Het lijkt mij op dit moment dat de WordPress-codebasis ernaar neigt om ons het PHP-proces te laten uitvoeren onder dezelfde gebruikers-principal als de bestandseigenaar voor de WordPress-toepassingsbestanden. Ik zou graag wat opmerkingen van de community hierover ontvangen.
Antwoord 13
Zoals vermeld door Niels, gebeurt dit omdat de gebruiker van het serverproces niet naar de WordPress-map kan schrijven.
Maar dit is wat veel artikelen niet uitleggen. Het is de eigenaar van het php-proces, niet het nginx-proces. Als je de nginx-eigenaar probeert te wijzigen, wordt dit niet opgelost.
Om het op te lossen, probeer ps auxuit te voeren om te zien welke gebruiker eigenaar is van het php-fpm-proces. Controleer vervolgens of de gebruiker dezelfde gebruiker is als de eigenaar van de wordpress-map, of er op zijn minst naar kan schrijven. Als de gebruiker er niet naar kan schrijven, moet u de machtigingen en/of het eigendom van de map wijzigen; of plaats de twee gebruikers (servereigenaar en wordpress-mapeigenaar) in een gemeenschappelijke groep die naar de map kan schrijven; of verander de eigenschap “user” van php.ini in een gebruiker die naar de map kan schrijven.
Antwoord 14
Ik had hetzelfde probleem!
Ik heb de onderstaande code toegevoegd in het bestand wp-config.php (in elke regel) en het werkt nu!
define('FS_METHOD', 'direct');