Categorieën
SQL WordPress

WordPress meta veld met URL zonder http://

Afgelopen maanden ben ik een aantal keer WordPress websites tegen gekomen met berichten waarbij in een meta veld een URL naar een externe website werd opgeslagen. In veel gevallen was deze URL echter niet voorzien van het http:// protocol prefix. Dit resulteerde aan de voorkant van de website in onjuiste URL’s.

Als binnen een WordPress bericht in een meta veld ‘website’ alleen ‘www.domeinnaam.tld’ stond resulteerde dit in de volgende link: http://website.tld/2012/08/wordpress-bericht/www.domeinnaam.tld/, terwijl dit eigenlijk: http://www.domeinnaam.tld/ had moeten zijn. Dit probleem is echter eenvoudig op te lossen met een database query.

Met behulp van de volgende query zijn URL’s zonder de http:// protocol prefix op te vragen:

SELECT
	*
FROM
	wp_postmeta 
WHERE
	meta_key = 'website'
		AND
	meta_value != ''
		AND
	meta_value NOT LIKE 'http%'

Als de ouput van deze query correct is dan kan met behulp van de volgende query de URL’s uitgebreid worden met het http:// protocol.

UPDATE 
	wp_postmeta 
SET 
	meta_value = CONCAT('http://', meta_value)
WHERE
	meta_key = 'website'
		AND
	meta_value != ''
		AND
	meta_value NOT LIKE 'http%'
;
Categorieën
Geen categorie PHP SQL WordPress

WordPress gebruikers niet in auteur dropdown

Bij veel geavanceerdere WordPress websites zijn de standaard WordPress gebruikersrollen en bijbehorende mogelijkheden (capabilities) niet meer voldoende. Gelukkig zijn deze gebruikersrollen eenvoudig met allerlei plugins te beheren en uit te breiden. Zo kan men bijvoorbeeld met behulp van de Members plugin dit alles via eenvoudige gebruikersinterface beheren.

Toch blijken er ook nog wel een aantal nadelen te kleven aan het inzetten van maatwerk gebruikersrollen. Zo loop ik regelmatig tegen het probleem aan dat gebruikers met maatwerk gebruikersrollen niet zichtbaar zijn de auteur dropdown. Hierdoor hebben eindbgeruikers niet de mogelijkheid om een gebruiker met maatwerk rol als auteur toe te wijzen aan een WordPress bericht.

Dit probleem wordt veroorzaakt doordat binnen de auteur meta box gebruik gemaakt wordt van de wp_dropdown_users() functie. De wp_dropdown_user() functie maakt op zijn beurt weer gebruik van get_users() en dus WP_User_Query. Met behulp van deze query klasse kunnen gebruikers opgevraagd. Met de ‘who’ parameter kan er geselecteerd worden op alle gebruikers of enkel auteurs.

Binnen de auteur meta box worden alleen de auteurs weergegeven. De implementatie van WP_User_Query vraagt de auteurs echter op aan de hand van het gebruikersniveau (level). WordPress gebruikersniveaus is een techniek die werd gebruik in WordPress versies voor 2.0. Tegenwoordig wordt bij het aanmaken van maatwerk gebruikersrollen deze gebruikersniveaus niet meer meegenomen.

In veel gevallen is het echterwel  verstandig om ook de gebruikersniveaus te koppelen aan maatwerk gebruikersrollen. Dit kan eenvoudig gerealiseerd worden door met behulp van de Members plugin respectievelijk de volgende mogelijkheden (capabilities) toe te voegen:

  • level_0
  • level_1
  • level_2
  • level_3
  • level_4
  • level_5
  • level_6
  • level_7
  • level_8
  • level_9
  • level_10

Dit zorgt ervoor dat zodra er gebruikers met een maatwerk gebruikersrol worden aangemaakt het gebruikersniveau niet op 0 blijft staan. Doordat deze niet op 0 blijft staan zullen deze gebruikers automatisch ook in de auteur dropdown weergegeven worden. Indien je al veel gebruikers met gebruikersniveau 0 in je systeem hebt staan dan kun je deze eenvoudig bijwerken met behulp van de volgende query:

UPDATE 
	wp_usermeta
SET 
	meta_value = 4
WHERE
	meta_key = 'wp_user_level'
		AND
	meta_value = 0
		AND
	user_id IN (
		SELECT 
			user_id 
		FROM (
			SELECT
				DISTINCT user_id 
			FROM 
				wp_usermeta
			WHERE 
				meta_key = 'wp_capabilities'
					AND
				meta_value LIKE '%company_author%'
		) AS temporary_table
	);

Met behulp van bovenstaande query upgrade ik gebruikers met de gebruikersrol ‘company_author’ en gebruikersniveau 0 naar gebruikersniveau 4.

Categorieën
WordPress

Plesk zero-day beveiligingslek WordPress website hack

Vorige maand berichten verschillende websites al over een zero-day beveiligingslek in Plek. Hierdoor zouden duizenden websites geïnfecteerd zijn geraakt met ongewenste zaken. Ik merk zelf dat ook veel Nederlandse de dupe zijn geworden van deze beveiligingslek. Op Security.nl is in het bericht “Hacker verkoopt zero-day voor onbekend Plesk-lek” hierover het volgende te lezen:

Onlangs rapporteerde een beveiligingsonderzoeker van Sucuri een toename van het aantal aanvallen op Plesk beheerderspanelen.

Op het Plesk-forum klagen verschillende gebruikers dat hun websites zijn gehackt, ook al gebruiken ze de laatste versie.

Meer informatie over deze beveiliginslek in Plesk:

Categorieën
PHP WordPress

WordPress eenvoudig in debug mode

Elke WordPress ontwikkelaar moet wel eens snel een probleem oplossen op een website die al live staat. Om problemen op te lossen is het vaak handig om te werken in debug mode. In een live omgeving is dit echter vaak niet een goed idee, omdat bezoekers dan onnodige meldingen te zien krijgen. Dit is echter eenvoudig te omzeilen door het volgende in het wp-config.php bestand te zetten:

define( 'WP_DEBUG', filter_input( INPUT_GET, 'debug', FILTER_VALIDATE_BOOLEAN) );

Vervolgens kun je eenvoudig de WordPress website in debug mode zetten door deze als volgt op te vragen:

  • http://domeinnaam.tld/?debug=true

Ook de volgende varianten zullen functioneren dankzij de krachtige FILTER_VALIDATE_BOOLEAN validatie filter.

  • http://domeinnaam.tld/?debug=1
  • http://domeinnaam.tld/?debug=on
  • http://domeinnaam.tld/?debug=yes

Het is waarschijnlijk wel verstandig om deze functie na het oplossen van het probleem weer te verwijderen en debug mode gewoon op ‘false’ te zetten.

Categorieën
Geen categorie WooCommerce WordPress

WordPress Shopp (nl) plugin

Onlangs kwam ik een WordPress website met de Shopp webwinkel plugin tegen met daarop ook de “Tussendoor Shopp 1.2.* NL / Dutch plugin“. Aangezien ik zelf ook een aantal vertaal plugins in beheer heb was ik wel benieuwd naar de opzet van deze plugin. Na het doorbladeren van de code kwam ik er snel echter dat het ging om een aangepaste versie van de WooCommerce (nl) en/of Gravity Forms (nl) plugin.

Tussendoor heeft helaas niet even de moeite genomen om Pronamic hiervan op de hoogte te brengen. Ik ben niet helemaal bekend met de regels die beschreven in de GPL licentie, maar even vermelden dat de plugin op onze plugins is gebaseerd zou ik wel gewaardeerd hebben.

The work must carry prominent notices stating that you modified it, and giving a relevant date.

Ik heb Tussendoor nog even via Twitter gewezen op de ontbrekende credits, maar daar is helaas niet op gereageerd.

Ik weet dat onze Duitse buren ook een variant op de WooCommerce (nl) plugin hebben gemaakt, namelijk de WooCommerce (de) plugin. Deze ontwikkelaar geeft ons echter alle credits voor ons werk:

Danksagung und Copyright: Dieses Plugin ist ein Fork des hervorragenden “WooCommerce (nl)” Plugins von Pronamic, NL bzw. Remco Tolsma @pronamic. Es ist quasi die Deutsche Version davon. Es steht genauso wie die ursprüngliche Code-Basis unter GPLv2-Lizenz (oder höher). — Ein grosses Dankeschön an Pronamic, die den Weg geebnet haben! 😉

Het is jammer om te zien dat onze concullega’s uit Friesland onze code zonder vermelding gebruiken. Het gaat hier natuurlijk niet om de meeste spannende plugin, maar ik dacht wel wat Tussendoor kan kunnen wij beter. Daarom hebben we recent de Shopp (nl) plugin gelanceerd. Deze plugin is inmiddels uitgerust met de vertaling voor de volgende Shopp versies:

  • 1.2
  • 1.2.2
  • 1.2.3

We hebben al veel vertalingen verbeterd, maar waarschijnlijk zijn er nog steeds veel verbeteringen mogelijk. Heb je zelf suggesties voor betere vertalingen dan horen we het graag. Mocht je geïnteresseerd zijn in een WordPress webwinkel met Shopp, WooCommerce, WP e-Commerce, WooCommerce, eShop of een andere WordPress webwinkel plugin dan kun je uiteraard ook altijd vrijblijvend een offerte aanvragen.