Computer: Meine Websites mit WordPress

Das  Webauthoring für fast alle meine Websites habe ich nach und nach auf WordPress umgestellt.

Dazu habe ich folgendes dokumentiert:

Besonders hilfreich finde ich die Möglichkeit in WordPress sog. Plugins zu verwenden. In regelmäßigem Einsatz habe ich folgende Plugins:

  • Last Modified Timestamp
  • Meta Slider
  • Page Meta
  • Table of Contents Plus
  • Updraft Plus
  • WordPress Flickr Embed Plus

xxxx

WordPress: Welche Datenbank Version von MySQL oder MariaDB

WordPress bei Strato funktioniert nicht mehr

Anfang Januar 2017 funktionierte mein WordPress-Blog http://blog.kr8.de  bei meinem Web-Hoster Strato nicht mehr richtig.
Die Ursache des Problems bei Strato ist ungeklärt.
Bei Strato sichere ich mein WordPress mit dem Plugin UpdraftPlus auf meine Dropbox – und das hat noch funktioniert.

Die Ursache: utf8mb4

Um weiter arbeitsfähig zu bleiben, wollte ich die Updraft-Sicherung von Strato in mein lokales WordPress einspielen was aber zu einer Fehlermeldung führte, die sagte, dass meine MySQL-Version zu alt dafür sei. Weitere Recherchen ergaben, dass es an der MySQL collation “utf8mb4_unicode_ci” liegt, die das WordPress bei Strato verwendet aber von meinen lokalen MySQL 5.0 nicht unterstützt wird.

Meine lokalen WordPress-Installationen verwendeten als Datenbank MySQL in der Version 5.0.41 und diese unterstützten utf8 aber nicht  utf8mb4.  Letzteres bildet ein utf-Zeichen auf 4 statt drei Bytes ab.

Die Lösung Migration auf MySQL 5.5

Die Lösung war, das lokale MySQL von Version 5.0 auf Version 5.5 hoch zu migrieren. Allerdings ist die Version 5.5 schon eine Oracle-Version; ich werde also prüfen, ob ich mittelfristig besser auf MariaDB umsteige.

Die Migration von MySQL-Versionen funktioniert wie folgt:

  • Mit Windows-Service Mysql50: mysqldump -uroot -p –all-databases > dump50.sql
  • Mit Windows-Service Mysql51: mysql -uroot -p <dump50.sql
  • Mit Windows-Service Mysql51: mysql_upgrade  -uroot -p

Datenbank-Kopien mit Updraft Plus

Wenn ich eine Updraft-Datensicherung einer WordPress-Installation in eine andere einspiele ist das nicht ganz korrekt. Ich muss auf das Datenbank-Präfix achten und der Wert für “siteurl” in der Datenbanktabelle “<praefix>_options” muss manuell angepasst werden.

WordPress auf der Synology Diskstation (mit MariaDB)

Installation von WordPress auf der Diskstation DS414

Auf meiner Synology Diskstation DS414 kann ich auch ein WordPress einrichten. Vorbedingung dafür ist (u.a.) die Installation des Datenbanksystems “MariaDB”, was die Diskstation anstelle von MySQL benutzt. MariaDB ist ein sog. fork von MySQL, den die ursprünglichen Entwickler von MySQL vorgenommen hatten, nachdem MySQL an Sun und schließlich an Oracle verkauft worden war.

Auf meiner Diskstation DS414 laufen nun als Dienste:

  • MariaDB Version 5.5.53
  • WordPress Version 4.6.1
  • Apache 2.2
  • PHP 5.6

Konfiguration von WordPress auf der Diskstation DS414

Standardmäßig wird WordPress auf der Diskstation in den Ordner  /volume1/web/wordpress installiert und wird dann mit der URL  http://diskstation/wordpress  aufgerufen.

Da ich als URL aber gerne mein vertrautes http://diskstation/blog.kr8.de haben wollte, habe ich zum Ordner “wordpress” einen Symlink “blog.kr8.de” eingerichtet (per SSH einfach den Befehl ln -s ….). Ich dachte, dann kann die Diskstation das WordPress in unveränderter Art und Weise Starten, Überwachen etc da ja der Name gleichbleibt.

Allerdings kam das WordPress selbst jetzt ein bisschen durcheinander, denn als siteurl stand in der Datenbank ja immer noch der Wert “wordpress”.  Ich habe also in der Datenbanktabelle wp_options den Wert für siteurl auf “diskstation/blog.kr8.de” geändert, was aber zunächst nicht die erhoffte Wirkung hatte, weil offenbar der Wert für siteurl festverdrahtet in der Datei wp-config.php stand (und die Datenbank dazu garnicht genommen wurde):

if ($_SERVER["HOST"] != "") {
define('WP_SITEURL', $pageURL);
} else {
define('WP_SITEURL', $pageURL.'/wordpress');
}

Erst nachdem ich auch hier “/wordpress” in “/blog.kr8.de”  umgeändert hatte, lief mein WordPress auf der Diskstation DS414 sauber unter der url http://diskstation/blog.kr8.de

Ich habe dann aber noch den owner des Ordners  “blog.kr8.de” auf “admin” geändert, weil es bei Update von WordPress-Plugins zu Fehlern durch unzureichende Zugriffsrechte kam.

UpdraftPlus mit WordPress auf der Diskstation mit MariaDB

Nachdem nun alles mit WordPress perfekt auf der Diskstation Ds414 lief, habe ich noch ausprobiert, das am 8.1.2017 mit UpdraftPlus bei Strato gemachte Datenbank-Backup auf der Diskstation einzuspielen. Die MariaDB hat es anstandslos geschluckt.

Es könnte also sinnvoll sein, meine MySQL-Installationen auf den Windows-Rechnern ebenfalls durch MariaDB zu ersetzen…

WordPress: Graphics SVG, SWF, ODG, VSD, PPT

Grafiken in WordPress

Auch in WordPress-Artikeln und -Seiten möchte man ja ab und zu auch schöne Vektorgrafiken einbauen – nicht nur Pixel-Bilder.

Je nach Format (SVG, SWF, ODG, VSD, PPT,…) sind da unterschiedliche Lösungen möglich, wo bei schon das Upload solcher Grafiken ein Problemchen sein kann.

SVG Graphics

SVG Upload

Source: https://wordpress.org/support/topic/svg-upload-not-allowed

SVG upload not allowed?? (9 posts)

  1. I’m trying to put an SVG image into a post, but I can’t upload it.

    “Harajuku map.svgz” has failed to upload due to an error
    Sorry, this file type is not permitted for security reasons.

    What gives?! It’s just an image!

  2. You can overcome the security warning by adding this to your current themes functions.php file.

    add_filter('upload_mimes', 'custom_upload_mimes');
    
    function custom_upload_mimes ( $existing_mimes=array() ) {
    
    	// add the file extension to the array
    
    	$existing_mimes['svg'] = 'mime/type';
    
            // call the modified list of extensions
    
    	return $existing_mimes;
    
    }

    Then you should be able to upload files with an .svg extension

SVG Embedding

xxxxxxx

SWF Graphics

Plugin Method

Source: http://www.wpbeginner.com/wp-tutorials/how-to-embed-swf-in-wordpress-posts/

First, you need to download and install Easy Flash Embed for WordPress. This plugin is so simple that no settings are even added to your admin menu. All you have to do is used a shortcode when you are creating your posts like this:

1 [swf src="http://www.example.com/my-flash-file.swf" width=300 height=100]

Simply replace the src attribute with a link to your flash file and adjust height and width accordingly.

Download Easy Flash Embed plugin.

[swf src=”/wp-content/uploads/2016/08/Agility.swf” width=300 height=300]

Agility

Code Method

For those of you who would like more control over your code we are now going to show you how to embed flash files directly into your WordPress posts, pages, or even themes. Although people have come up with numerous methods for doing this over the years the easiest and most standards compliant way is to use the <object> element.

The final code looks like this:

01 <object id="flashcontent"
02         classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
03         width="550px"
04         height="400px">
05   <param name="movie" value="mymovie.swf" />
06  
07   <!--[if !IE]>-->
08   <object type="application/x-shockwave-flash"
09           data="mymovie.swf"
10           width="550px"
11           height="400px">
12   <!--<![endif]-->
13  
14     <p>
15       Fallback or 'alternate' content goes here.
16       This content will only be visible if the SWF fails to load.
17     </p>
18  
19   <!--[if !IE]>-->
20   </object>
21   <!--<![endif]-->
22  
23 </object>

Note that you are using 2 <object> elements. The outer element is targeting Internet Explorer while the inner element is for all the other browsers. You can change your fallback text if necessary. You can also add extra <param> options like wmode or allowScriptAccess.

P.S. you should always use wmode=transparent, so your embed doesn’t override existing content such as a floating bar. Check out our article on how to prevent Youtube oEmbed from overriding content.

 

 

Other Graphics: ODG, VSD, PPT

WordPress: Evolution from B2/Cafelog to WordPress 1.0

post-page

Evolution of WordPress: B2/Cafelog to WordPress 1.0

by on July 14th, 2008 in WordPress

A few days ago we had told you what you should know about WordPress 2.6. The post described new features that will be introduced shortly in WordPress 2.6. Though there are several new features that you may like in this new version, there might be many that have gone unnoticed that were introduced in the earlier versions of WordPress. To quell the anticipation that users might have for the latest version, we wanted to write a series of posts that will cover WordPress from its infancy to WordPress 2.5 (the latest major version) that many of you use.

The WordPress team has been naming their major releases after popular Jazz legends and we will take a look at code names for the past releases.

B2 / Cafelog

WordPress is the official successor of B2/Cafelog which is a blogging platform created in early 2001 by Michel Valdrighi using PHP and MySQL. Matt Mullenweg and Mike Little took over the development to come up with (fork?) the WordPress platform as we officially know it now in early 2003, giving birth to one of the best blogging platforms ever developed.

WordPress 0.7 – 0.71

The first version to come out under the new name was WordPress 0.7 which was released in May 2003, marking several changes over the B2/Cafelog software. WordPress 0.7 introduced several new features such as allowing users to add links to their blogrolls, new administration interfaces, manual excerpts, default templates and more.

WordPress 0.71 was just a minor revision but it brought incorporated many changes that form an integral part of WordPress as we know it today. WordPress 0.71 “Gold” introduced cool new features such as post status where users could mark the post state as draft, publish or private. A blog owner would also have greater flexibility over the comments by disabling them on a per-post basis. 0.71 also combined trackbacks, pingbacks and user written comments into a single category. There were several other changes including better administration, security fixes and more.

WordPress 0.72 added password protected posts, new xmlrpc APIs, a Blogger import and many other improvements. This version also included a new theme from Dave Shea.

WordPress 1.0

There were several minor versions in between WordPress 0.71 and WordPress 1.2 beside WordPress 1.0, which included WordPress 1.0.1 code named “Miles”. This was followed by WordPress 1.0.2 code named “Blakey” which was a smaller release based on bug fixes.

The much anticipated WordPress 1.0 was finally released on January 3rd, 2004. This version included several new exciting features (as usual). The most noticeable feature was the introduction of better search engine friendly permalinks which allowed users to structure their URLs to get better search engine visibility using mod_rewrite. The version also lifted the limitation of allowing only one category per post. This meant that users could assign several categories to a single post.

For all those who were worried about comment spam, this version included comment moderation where blog authors could moderate comments, before they would be viewable on the blog. Users could also edit pages or comments with the newly provided links. WordPress 1.0 also included support for ATOM based feeds. 1.0 was a very popular release.

There were several other new releases which we will take a look in other parts of this series. In the mean time, we would love to hear from users who had used these versions. How did the earlier versions of WordPress change your outlook towards blogging? Did those earlier versions make you a fan?

[EDIT] Fixed minor error in versions and added 0.72. Thanks Carson and Geof

WordPress Menüs – Navigation

Menüs zur Navigation zu WordPress-Seiten, kann man ja sehr intuitiv im WordPress-Backend unter dem Punkt “Design > Menüs” einrichten.

Zuvor muss jedes Menü aber “angemeldet” werden. Diese Anmeldung geschieht bei WordPress-Thems in der PHP-Datei “functions.php”.
Nachdem ein Menü in “functions.php” angemeldet wurde und im WordPress-Backend von seiner Struktur her definiert wurde, muss man als dritten Schritt noch für die Ausgabe des Menüs sorgen.

WordPress-Menü anmelden in “functions.php”

 
Die Anmeldung der Menüs erfolgt mit der PHP-Funktion “register_nav_menues()” und kann etwa wie folgt aussehen:
 
register_nav_menus( array(
             primary =>  Erstes Menu ,
             secondary => Zweites Menu,
             tertiary => Drittes Menu,
      ) ) ;
 
Man spricht von “slugs”  ( primary, secondary, tertiary) und “descriptions”  (Erstes Menu, Zweites Menu, Drittes Menu).
Die Bezeichnungen ‘Erstes Menu’, ‘Zweites Menu’ und ‘Drittes Menu’  erscheinen dann im WordPress-Backend unten unter Menü-Einstellungen – Position im Theme.

Menü-Strukturen definieren im WordPress-Backend unter Design > Menüs

 
Im WordPress-Backend werden nun Menü-Strukturen (Hierarchie von Seiten) definiert.  Die Seiten müssen zu diesem Zeitpunkt schon mal vorhanden sein – ggf. nur als Dummies mit leerem Inhalt o.ä.

Im WordPress-Backend  bekommt jede hier angelegte Menü-Struktur einen weiteren sprechenden Namen, der ausschließlich hier im WordPress-Backend zur Benennung und Auswahl (“Wähle ein Menü zum Bearbeiten:…” – richtiger Weise “Wähle eine Menü-Struktur….”) benutzt wird. Ich kann hier beliebig viele Menü-Strukturen definieren. Muss dann aber letztlich jedem angemeldeten Menü (s.o.) eine Menü-Struktur zuordnen. Dazu wird bei einer Menü-Struktur unten im WordPress-Backend unter Menü-Einstellungen – Position im Theme eine “Description” ( ‘Erstes Menu’, ‘Zweites Menu’ und ‘Drittes Menu’ ) angehakt.

WordPress-Backend: Menüstruktur

WordPress-Backend: Menüstruktur

WordPress-Menü Ausgeben auf die Web-Seite

 
Für die Ausgabe eines Menüs ist die Position (Ort)  auf der Web-Seite und die Gestaltung des Menüs (Farben, Schrift, Kästchengröße, Verhalten bei Klick, Hover etc.) anzugeben.
Typischweise ist der Ort eines Menüs im Header-Bereich – kann aber auch an anderen Stellen plaziert werden.
Die Ausgebe-Befehle (z.B. in der PHP-Datei “header.php”) erfolgt mit der PHP-Funktion “wp_nav_menu()” und kann etwa wie folgt aussehen:
   <?php
                      wp_nav_menu( array(
                          theme_location     => primary,
                          depth              => 2,
                          container          =>  div,
                          container_class    => collapse navbar-collapse navbar-ex1-collapse,
                          menu_class         =>  nav navbar-nav,
                          fallback_cb        => wp_bootstrap_navwalker::fallback,
                          walker             => new wp_bootstrap_navwalker())
                      ) ;
        ?>
Man sieht, dass hier die Menüs mit ihrem “slug” (also ‘ primary’, ‘ secondary’ etc.),  so wie bei der Anmeldung vergeben, identifiziert werden.
Die Gestaltung (Aussehen) des Menüs erfolgt dann durch die diversen CSS-Klassen ( z.B. “nav”, navbar-nav”) und das  “Walker-Objekt”…..

WordPress Desktop Blogging: 5 Tools Reviewed

Source: http://www.centernetworks.com/wordpress-desktop-blogging

I was about to write a blog post when it hit me. It was like a blinding realization… a moment of pure truth. I hate the WordPress post editor. In fact, I’m not too fond of the entire admin area, but I love wordpress as a whole package. So, why haven’t I researched desktop WordPress clients? And thus, the idea for this post was born. To my amazement, I found that there were quite a few blog administrator applications for the desktop. For my particular application, though it had to meet a few requirements.

  • It has to administer WordPress
  • It has to run on windows

Contine reading