Advertentie
De kern van elke WordPress-installatie is de wp-config.php bestand, een bestand zo heilig en gehuld in mysterie dat elke WordPress-gebruiker weet dat het zou moeten nooit aangeraakt worden.
Of toch?
Sterker nog, er zijn veel minder bekende nuttige hacks die WordPress op geen enkele manier kunnen beschadigen, en het wordt hoog tijd dat je je WordPress-vaardigheden een stapje verder gaat. Lees verder voor 5 van mijn favoriete wp-config-trucs.
Dit artikel is uitsluitend bedoeld voor door uzelf gehoste WordPress.org-sites, niet die gehost op WordPress.com (wat is het verschil? Wat is het verschil tussen het runnen van uw blog op Wordpress.com en Wordpress.org?Nu Wordpress nu 1 op de 6 websites van stroom voorziet, moeten ze iets goed doen. Voor zowel ervaren ontwikkelaars als de complete beginner heeft Wordpress u iets te bieden. Maar net als je begint ... Lees verder ).
Voordat u begint, moet u weten dat u het laden van WordPress mogelijk kunt stoppen als u de syntaxis van dit bestand verknoeit, zelfs met iets zo dwaas als het vergeten van een puntkomma. Het is echter ook ongelooflijk eenvoudig om het te dupliceren voordat je begint met bewerken, zodat je een back-up hebt. Als je iets kapot maakt, verwijder dan gewoon je gewijzigde bestand en hernoem de back-up - alles komt weer goed met de wereld. Het is eigenlijk heel moeilijk om een WordPress-installatie permanent te beschadigen, in plaats van je hele database te verwijderen. Voordat u een van deze probeert, wilt u misschien ook onze bekijken
ultieme gids voor het oplossen van 500 interne serverfouten De ultieme gids voor het oplossen van 500 interne serverfouten en lege witte pagina's in WordPressHeeft u problemen met 500 interne serverfouten en blanco pagina's in WordPress? Hier leest u hoe u ze meteen kunt oplossen. Lees verder .Het wp-config.php-bestand staat in de root van uw WordPress-installatie en vereist dat u zich aanmeldt via FTP of SFTP om het te bewerken. Als u niet zeker weet hoe u dat moet doen, is de inhoud van dit artikel mogelijk niet geschikt voor uw vaardigheidsniveau - maar hier zijn enkele nuttige IFTTT-recepten voor gebruik met WordPress 5 geweldige IFTTT-recepten voor WordPress-gebruikersIFTTT is de favoriete automatiseringstool van de gebruiker; en WordPress is het ultieme Zwitserse zakmes voor bloggers. Stel je eens voor wat voor wereldheerschappij je zou kunnen bereiken door de twee te combineren! Lees verder (zonder dat je bestanden hoeft te bewerken).
Log fouten in een bestand
Soms is het niet wenselijk om een heleboel vervelende fouten in de openbare front-end van uw site te plaatsen. Registreer de fouten in plaats daarvan in een bestand! Definieer het volgende, wacht even en je ziet een nieuwe error.log in de wp-content / directory langzaam vol. Het is een goed idee om dit uit te schakelen zodra u een voldoende voldoende voorbeeld van de fouten heeft, aangezien er is geen ingebouwde log rotatie of limieten - je zou je hele server kunnen vullen met gigabytes aan logs!
define ('WP_DEBUG', waar); // verander terug naar false om uit te schakelen. if (WP_DEBUG) {define ('WP_DEBUG_LOG', waar); definieer ('WP_DEBUG_DISPLAY', false); @ini_set ('display_errors', 0); }
Zoek naar lijnen met PHP_ERROR liever dan MERK OP of WAARSCHUWING - de laatste zal uw site niet breken, maar de eerste wel.
Post Revisies uitschakelen
Ik heb ooit een bericht gevonden met meer dan 100 revisies: dat zijn 100 extra rijen in de berichtentabel die niet nodig zijn. Schakel postrevisies volledig uit met de volgende eenvoudige regel:
definieer ('WP_POST_REVISIONS', false);
of
definiëren ('WP_POST_REVISIONS', 3);
om ze te beperken tot een redelijk aantal. Natuurlijk vinden sommige mensen het leuk om post-revisies te hebben, vooral in een omgeving waar redacteuren wijzigingen in uw aanbrengen werk - maar als je alleen maar schrijft en je hebt de neiging om beetje bij beetje aan berichten te werken, is het gewoon niet de moeite waard het. Houd er rekening mee dat deze truc geen bestaande postrevisies verwijdert, maar dat er geen nieuwe worden gemaakt.
Gedeelde gebruikerstabel
Soms wil je meer dan een WordPress-installatie - dat doen we hier bij MakeUseOf.com. Maar gebruikers een aparte login geven voor elke site is gewoon belachelijk, en het runnen van een "multisite" netwerk van blogs helpt ook niet (geloof me, we hebben het geprobeerd) - in feite maakt het de situatie te ingewikkeld wanneer een paar regels in je wp-config.php echt alles is wat nodig is. Wat je wilt, is wat een gedeelde gebruikerstabel wordt genoemd, dat wil zeggen, hoewel elke blog zijn eigen entiteit blijft met afzonderlijke plug-ins en berichten, enz., Wordt alleen de gebruikersdatabase gedeeld.
Bepaal eerst uw hoofdblog - dit is waar gebruikersbeheer wordt gedaan. Laten we het blog A noemen. Blog B en C worden 'subblogs' en putten uit de gebruikerstabel van de hoofdblog A, en ik neem aan dat ze in afzonderlijke mappen worden geïnstalleerd. Voeg in de wp-config-bestanden voor B en C de volgende regels toe. In dit voorbeeld gebruikt de hoofdblog een databasevoorvoegsel "blogA".
definiëren ('CUSTOM_USER_TABLE', 'blogA_users'); definiëren ('CUSTOM_USER_META_TABLE', 'blogA_usermeta');
Het databasevoorvoegsel is een specifieke term die is gekozen tijdens het instellen van je eerste blog (degene die wordt gebruikt om alles te beheren). De standaard is wp_ maar nieuwe installaties zullen u aanmoedigen om dit te veranderen. Als u het niet zeker weet, is dit het woord dat aan het begin staat van al uw databasetabelnamen.
U moet er ook voor zorgen dat cookiedomeinen hetzelfde zijn - zonder deze stap moeten gebruikers afzonderlijk inloggen op elke site (zij het met hetzelfde wachtwoord en dezelfde mogelijkheden, die nu worden gedeeld).
definiëren ('ADMIN_COOKIE_PATH', '/'); definiëren ('COOKIEPATH', '/'); definiëren ('SITECOOKIEPATH', '/'); definiëren ('COOKIEHASH', md5 ('CHANGETHIS'));
Zorg ervoor dat u CHANGETHIS vervangt door uw eigen willekeurig gegenereerde reeks tekens om uw cookies te beveiligen. Ten slotte zou u een aantal regels moeten zien die lijken op de onderstaande schermafbeelding, gedefinieerd met willekeurige waarden voor "zout" en "sleutel". Zorg ervoor dat dit hetzelfde is in elk configuratiebestand; als je er nog geen hebt, gebruik dan deze pagina om ze te genereren.
Gelukkig gaan geen van de wijzigingen die u aanbrengt in wp-config.php verloren bij elke upgrade, maar er is nog een kleine wijziging die u mogelijk opnieuw moet aanbrengen als de upgrade deze overschrijft: in wp-include / capabilities.php.
De _init_caps () functie is waar de mogelijkheden voor de huidige gebruiker worden opgehaald - als we dit niet wijzigen, kan de gebruiker inloggen, maar eigenlijk niets doen. Zoek de volgende code:
function _init_caps ($ cap_key = '') {global $ wpdb; if (leeg ($ cap_key)) $ this-> cap_key = $ wpdb-> get_blog_prefix (). 'mogelijkheden'; anders $ this-> cap_key = $ cap_key; $ this-> caps = get_user_meta ($ this-> ID, $ this-> cap_key, true); als (! is_array ($ this-> caps)) $ this-> caps = array (); $ this-> get_role_caps (); }
en verander de
$ this-> cap_key = $ wpdb-> get_blog_prefix (). 'mogelijkheden';
dus het is hard gecodeerd naar wat je belangrijkste blogprefix is
$ this-> cap_key = 'blogA_capabilities';
Controleer bij elke upgrade of je nog steeds volledige toegang hebt tot elke blog; zo niet, herhaal deze oplossing.
Bevestig de site-URL
Als je de URL-instellingen hebt verknald, kun je jezelf soms buitensluiten in het beheerdersgedeelte in een akelig kip-en-ei-scenario. Je zou het kunnen repareren met toegang tot de instellingen, maar je hebt geen toegang tot de instellingen omdat de instellingen verkeerd zijn; (
Gelukkig kun je alle database-opties overschrijven waar de URL is opgeslagen - voeg de volgende regels toe aan je configuratiebestand:
definieer ('WP_SITEURL', ' http://example.com/' );
definieer ('WP_HOME', ' http://example.com/' );
Verbreek de URL niet tijdens het migreren
Een WordPress-site migreren naar een nieuw domein 3 plug-ins voor het eenvoudig migreren van een WordPress-site, geprobeerd en getestDeze WordPress-plug-ins kunnen het hele proces van het migreren van een WordPress-site voor u semi-automatiseren. Lees verder kan op een paar manieren worden gedaan, maar als je voor de hardcore opdrachtregeldatabase en bestandsdump bent gegaan, is dit de meest gebruikelijke manier om de site ontoegankelijk te maken. In plaats van het achteraf te repareren, voegt u de volgende regel toe om WordPress in de relocate-modus te zetten.
define ('RELOCATE', waar);
Als je nu alles hebt gemigreerd, ga je naar /login.php en de URL-instellingen worden voor u bijgewerkt. Controleer of het werkte en verwijder deze regel uit de configuratie.
Het beheersen van uw wp-config.php is een stap op weg om het meesterschap van WordPress te voltooien - ik zou u ook aanraden om meer te leren over directe interactie met de database met deze handige SQL-queries 7 Wordpress-databasequery's om op uw blog naar alles te zoekenHet runnen van een WordPress-blog of een website is in het begin niet echt een groot probleem. Het is eigenlijk best simpel. Je installeert Wordpress op een webserver, je uploadt en installeert een thema, start ... Lees verder .
Heb je nog andere wp-config-hacks die je wilt delen?
James heeft een BSc in Artificial Intelligence en is CompTIA A + en Network + gecertificeerd. Hij is de hoofdontwikkelaar van MakeUseOf en brengt zijn vrije tijd door met het spelen van VR paintball en bordspellen. Hij bouwt al pc's sinds hij een kind was.