When your website is noch fully configured, the preview of your website link could be your favicon. Thats not the best version when you what to promote something. especially when you want to optimize your CTR.
First Guess: the meta image must be less than 300 KB
<meta property="og:image" content="//cdn.example.com/uploads/images/webpage_300x200.png">
Für mein Projekt www.autoachrichten.de habe ich gerade einen neuen Custom Post Type eingerichtet. Durch die WordPress Dokumentation auch kein großes Problem. In der functions.php kommt folgender Aufruf hinzu
add_action( 'init', 'create_post_type' );
function create_post_type() {
register_post_type( 'product',
array(
'labels' => array(
'name' => __( 'Products' ),
'singular_name' => __( 'Product' )
),
'public' => true,
'has_archive' => true,
)
);
}
Quelle: codex.wordpress.org
Durch dieses kleine PHP Snipped erscheint im Adminbereich ein neuer Eintrag im Menü. Hier können jetzt alle neuen Posts des neuen Post Types angelegt werden. In der Vorschau auch überhaupt kein Problem. Sobald der Artikel gespeichert ist und der neue Artikel über den Permalink aufgerufen wird, kamen bei mir durchgehend 404 Fehler.
Da ich jetzt eine Weile Googeln musst um dem Problem auf die Schliche zu kommen, wollte ich meine gefundenen Ergebnisse einmal zusammen tragen.
Alles hat bei mir nicht zugetroffen. Die Lösung war dann doch sehr simpel: Damit der interne Cache aller Rewrite Rules geleert wird, muss einmal die Permalink Seite im WP-Admin aufgerufen werden. Bei ganz hartnäckigen Fällen sollt das ändern (und wieder zurück) der Permalink Struktur helfen. Jetzt ist der neue Custom Post Type auch in den Rewrite Rules vorhanden und die Seiten werden gefunden.
Wie bei allen arbeiten an WordPress sollte die Seite einmal gesichert werden um Datenverlust zu vermeiden.
Danke an wpmu.org, hier gab es die Fehlerlösung
wpmu.org/troubleshooting-wordpress-404-errors-with-custom-post-types/
Neuer Server, gleiche Fehlermeldungen.
Hier mal ein Klassiker, der bei jedem Projekt auftaucht bei dem erstmal Caching und Clientverhalten verbessert werden soll.
Hier handelt es sich nicht wirklich um einen Fehler, des fehlt nur ein Apache Modul, was noch gestartet werden muss. Es gibt zwei Möglichkeiten das zu tun. Die von mir beforzugte
a2enmod headers
mit diesem Befehl lassen sich auch alle anderen Module für den Apache aktivieren bzw. deaktivieren (a2dismod).
Der Vollständigkeit halber kann man ein Apache Modul auch manuell aktiven in dem man einen Symlink von “mods-available” nach “mods-enabled” setzt. Konkret sieht das dann so aus:
ln -sf /etc/apache2/mods-available/headers.load /etc/apache2/mods-enabled/headers.load
Wie bei allen Änderungen am Apache muss er auch in diesem Fall neu gestartet werden
/etc/init.d/apache2 restart
Viel Erfolg!
Nach den ersten zaghaften versuchen im letzten Jahr regelmäßig einen Artikel zu schreiben, habe ich mir nun wieder fest vorgenommen den “Artikel erstellen” Button im WordPress regelmäßig zu drücken.
Wo die Reise thematisch hin geht, ist offen. Durch meine verschiedenen Tätigkeitsfelder wird es auf jeden Fall gut durchmischt werden – Automotive, PHP, Zend, MySQL, Bash, Jenkins, VMware, Startup Insider, um nur ein paar zu nennen.
Bedingt durch den Aufbau der interen Qualitätssicherung in meiner Firma (Web on Mobile) dreht sich gerade alles die Buzzwords GIT, Jenkins, Continuous integration, Continuous Deployment, UnitTests, PHPDepend, Selenium und Co. Sicher ist das alles andere als Pionierarbeit und glücklicher weise gibt es bereits einige Artikel und Anleitungen die helfen voran zu kommen.
Genug Material für das nächste Thema gibt also mit Sicherheit!
Ich bin eigentlich davon ausgegangen, dass es in einem so spezialisierten und vor allem, weit verbeitetem Shop System nicht weiter kompliziert sein sollte, die Telefonnummer als Pflichtfeld beim Checkout-Prozess zu entfernen. Dem ist aber leider nicht so. Es bleibt nur zu hoffen, dass es in den nächsten Versionen einfacher wird, die Felder und deren Eigenschaften einfacher zu verwalten.
Wie allzu oft gibt es hier leider auch keinen goldenen Weg, das Problem zu beheben. Auf der Suche nach der Lösung für meinen Fall bin ich auf verschiedene Ansätze aus verschiedenen Versionen gestoßen.
Kurze Beschreibung für die Aktuelle Magento-Version 1.6, die bei mir zu Erfolg geführt hat.
In diesem Fall sind 3 Sachen zu tun.
SELECT * FROM eav_attribute WHERE attribute_code = 'telephone';
Um das Feld dann zu ändern, dann folgenden Befehl:
UPDATE eav_attribute SET is_required = 0 WHERE attribute_code = 'telephone';
In meinem Shop gibt es das Billing Template auch noch mal unter:
Wenn diese Templates in eurem Theme nicht vorhanden sind, dann kopiert sie einfach aus dem Base Verzeichnis (Magento-Pfad/app/design/frontend/base/default/template/…) da sind auf jeden Fall alle Templates zu finden
cp app/code/core/Mage/Customer/Model/Address/Abstract.php app/code/local/Mage/Customer/Model/Address/Abstract.php
Wenn ihr keinen SSH Zugangn habt geht es natürlich auch mit einem gewohnten FTP Client.In der kopierten Datei sucht ihr nun nach folgender Codepassage (ist relativ weit unten):
if (!Zend_Validate::is($this-&gt;getTelephone(), 'NotEmpty')) {
$errors[] = $helper->__('Please enter the telephone number.');
}
Die drei Zeilen könnt ihr kommplett auskommentieren.
Nach diesen Änderungen, Cache löschen nicht vergessen, ist es nun Möglich den Checkout Prozess auch ohne Telefonnummer abzuschließen.
Quellen: