Hoernerfranzracing goes WordPress

Das ist eigentlich nichts wirklich neues, WordPress ist ja schon seit 2007 das Tool, mit dem der Weblog betrieben wird, und auch zunehmend die quasi statischen (Informations-)Seiten, aber die Basis war bisher immernoch ein Relikt aus den Anfangszeiten (vor dem Jahr 2000) – ein sog. Frameset.
Für handgemachte HTML-Seiten hat das den Vorteil, dass man die Navigation in einen eigenen Frame auslagern kann, und diese nicht auf jeder Seite duplizieren muss, sondern einfach verlinken kann, das spart schon einiges an Arbeit und vor Allem Pflegeaufwand (z.B. wenn sich das Menu ändert).

Allerdings kommen Framesets immer mehr aus der Mode, und das Ende der Unterstützung durch moderne Browser wird langsam absehbar.
Die technisch einfachste Alternative sind die Iframes, die sehr ähnlich funktionieren. Deswegen habe ich diese schon getestet, aber, mit Verlaub, es sieht einfach Schei..e aus .
Also doch lieber komplett auf ein modernes CMS umsteigen, und – da eh schon ein grosser Teil des Contents mit WordPress erstellt, wurde, fiel die Wahl leicht.
Der Hauptgrund, warum ich das nicht schon viel früher gemacht habe, ist das bisher für die Trainingsveranstaltungen verwendete, selbstprogrammierte Anmelde-und Verwaltungssystem – dieses wäre zwar innerhalb eines CMS auch wieder mit Iframes nutzbar gewesen, allerdings mit den genannten Nachteilen.
Alternativ natürlich auch durch Implementierung als WordPress-Plugin, aber das war mir dann doch zuviel 😀 . weiterlesen

https everywhere

Ab sofort auch für hoernernfranzracing.de: SSL Verschlüsselung !
Aktuell wächst der Druck auf Webseitenbetreiber/Besitzer, ihre Seiten auch oder ausschliesslich über https zugänglich zu machen, siehe z.B. ssl-zertifikat-januar-2017-pflicht und nun ist es auch hier soweit 😀 , erkennbar am kleinen Schloss und am ‚https://‘ der URL:
SSL Anzeige
Um dies zu erreichen, gibt es verschiedene Möglichkeiten, die sich deutlich in den Kosten, dem Einrichtungs- Administrations- und Betriebsaufwand, aber auch in der Sicherheit, die sie z.B. für Webshopkunden bieten, unterscheiden.

Was die Sicherheit angeht, unterscheidet man grob in 3 Kategorien: weiterlesen

Website Facelift

Nachdem ich mich nun auch beruflich mehr mit Webdesign, CSS, Javascript etc. beschäftige (Blogpost hierzu folgt…) habe ich mich entschlossen, auch der eigenen Website etwas Zuwendung angedeihen zu lassen 😀 .

Desktop-Nutzer werden davon kaum etwas merken (ausser dass ein paar verwaiste Links korrigiert wurden), aber Besucher mit Mobilgeräten sollten sich nun einfacher zurechtfinden, und vor allem die Seiten besser lesen und auch navigieren können. Das Ganze ist zwar noch weit entfernt von dem, was man heutzutage unter ‚Responsive Design‘ versteht, aber ich denke, es ist zumindest mal ein Schritt in die richtige Richtung. weiterlesen

KB Easy Gphotos

As already posted in my recent Picasaweb rant, the long time used KB Easy Picasaweb Plugin stopped working by mid 2016 because of Google deprecated their Picasaweb Photo Service in favour of Google Photos.
Given the fact that the original Plugin has not been changed/updated since 2010, there was little hope to get this adapted to work with Google Photos instead of Picasaweb (in Fact, I tried to contact the Author to ask if he would be willing to fix the Problem, or instead look at a modified Version to evtl. incorporate necessary changes, but unfortunately, got no answer so far).
So I decided to try to modify it so it would (at least) work for me. And, well, that’s exactly what I managed to get done now 😀
The modified Version has currently some Limitations compared to the Original:

  • username is no longer supported
  • Auth Key is no longer supported (so, only public Albums can be displayed)
  • Captions are not (yet) supported
  • you might encounter some unwanted (album unrelated) photos beeing displayed at the end of your list, but there is a workaround for that

As an improvement, a new Option has been introduced: use a ‚rel=numpics:xy‘ Tag in your URL to set the Number of displayed photos on a per-Link-Base – this will override the global plugin setting.
Visitors of hoernerfranzracing.de will not encounter much changes due to this new Plugin, as it works in nearly the same way as the old one – so just continue to have fun with the photos here 😀
Anyone who wants to try it, is invited to download the Plugin here – maybe I’ll upload it in the future to wordpress.org/plugins to make it available to a broader audience. weiterlesen

SPAM Schleuder :)

Hier mal wieder ein kleines Tool, entstanden aus aktuellem Anlass.
Wer kennt nicht das Problem, mal schnell eine email an eine Liste von Empfängern zu schreiben, ohne deren emailadressen allgemein publik zu machen und gleichzeitig ein wenig individuell zu wirken ?
Sicher, man kann die email an einen virtuellen Empfänger (oder an sich selbst) adressieren und alle andern auf BCC setzen, aber da fehlt dann halt die persönliche Note in Form einer individuellen Anrede (Hallo XYZ,).
Also schnell mal nach ’smtp send email python‘ gegoogelt und gleich alle notwendigen Tips gefunden (python gefällt mir immer besser, muss ich sagen..).
Ergebnis ist das hier veröffentlichte script, das gleich mal praktische Verwendung zum Versand einer aktuellen Einladung fand 😀
Und ja, es ist natürlich auch hervorragend als SPAM-Schleuder zu gebrauchen 😉
(Für eine solche Verwendung lehne ich nat. jede Verantwortung ab).
Quelltext:

#!/usr/bin/python
#	bulkmail.py: send bulk email to recipients in RecListFileName
#	Message is from MsgFileName, preceeded by 'Hallo <Name>,\n'
#	RecListFileName must contain one Recipient per line in the form 'Vorname Name <email>'
# Default Subject may be overridden in MsgFile (line starting with 'Subject:')

import os, sys

def send_email(TO, SUBJECT, TEXT):
    import smtplib
    import datetime

    date = datetime.datetime.now().strftime( "%d %b %Y %H:%M" )

    # Prepare actual message
    message = """From: %s\nTo: %s\nSubject: %s\nDate: %s\n\n%s
    """ % (FROM, ", ".join(TO), SUBJECT, date, TEXT)
    try:
        server = smtplib.SMTP(smtp_server, 25)    # be sure to use correct port (25 for std smtp, )
        server.ehlo()
        server.starttls()
        server.login(user, pwd)
        server.sendmail(FROM, TO, message)
        server.close()
    except:
        print "failed to send mail to %s" % (TO)

#  Config (global variables - use your own valid credentials instead :):
FROM = 'George Bush <ghwbush@whitehouse.gov>'
smtp_server = "srv1.whitehouse.gov"
user = "ghwbush"
pwd = "obama"
            
#	Defaults:                
TO = [FROM] #must be a list
SUBJECT = "Test bulk email"
TEXT = "Testing sending mail using whitehouse servers"
RecListFileName = "Recipients.lst"

NumArgs = len(sys.argv)
if (NumArgs < 2):
  print 'usage: %s RecListFileName MsgFileName' % (sys.argv[0])
  sys.exit()

RecListFileName = sys.argv[1] 
MsgFileName = sys.argv[2] 

# read message (and subject) from MsgFile
Msg = ''
try:
  MsgFile = open(MsgFileName, 'r')
  line = MsgFile.readline(); # read 1st line
  while (line):
    sline = line.strip()
    if (sline.startswith('Subject:')):
        # extract Subject
        SUBJECT = sline.replace('Subject:',  '')
    else:
        Msg += line
    line = MsgFile.readline()
        
  LogMsg = 'Message:\n' + Msg + '\nhas been sent to:\n'
  MsgFile.close()
except:
  print 'could not read %s - exiting' % (MsgFileName)
  sys.exit()

# process RecListFile, send emails to each recipient
try:
  RecListFile = open(RecListFileName, 'r')
  line = RecListFile.readline(); # read 1st line
  while (line):
    line = line.strip()
    if ((len(line) > 0) and not (line.startswith('#'))):
      TO = []
      TO.append(line)
      parts = TO[0].split(" ")
      Vorname = parts[0]
      TEXT = "Hallo %s,\n%s " % (Vorname, Msg)
      #print '%s' % (TEXT)
      send_email(TO, SUBJECT, TEXT)
      print 'Message from %s has been sent to: %s' % (MsgFileName, line)
      LogMsg += line
      LogMsg += '\n'
    line = RecListFile.readline()
except:
  print 'could not read %s - exiting' % (RecListFileName)
  sys.exit()
RecListFile.close()

# Log Message as email to Sender
TO = [FROM]
send_email(TO, SUBJECT, LogMsg)

Kdevelop for Web Developers

Basically, this is a follow-up on my Post about Quanta/Gubed several years ago. However, as Quanta is long dead now, unfortunately, there is clearly a need for a replacement, especially one that integrates well with KDE.

And no, I’m not going to bash established IDEs like eclipse, netbeans etc. – just a simple word: I personnaly don’t like dinosaurs 😀 . So, what’s left ? Short answer: Kdevelop . This, although commonly known as superior IDE for C++ development, especially under KDE, has come a long way and through its flexible plugin-structure, it is nowadays also a feasible alternative for other tasks, including development for scripting languages like php and python. This article will focus on the php side, as this is what I’m using it for 😀 . So, lets start with the basic features.
  • Project handling: Projects can be created from inside Kdevelop, there are templates for all kinds of projects, including php. On the other hand, it is also possible to simply open an existing directory with source files – voila, thats the new project.
  • Editing: Easy enough, as Kdevelop uses Kate as its default source code editor, which is just awesome, especally with php-documentation installed (this is usually done through  standard package managers). Syntax highlighting, code folding, online help, all is there.
But, what makes up a real, full-featured IDE ? – the integration of a powerful debugger, of course. For C/C++, it is well-known that Kdevelop integrates gdb very well, with everything needed is available as binary packages for virtually every distro. Nowadays, there is, fortunately, xdebug for php – integrated with Kdevelop through a plugin. So, lets focuse on this one. These are the prerequisites:
  • kdevelop in a recent version (I’m using 4.5.1 on Kubuntu 12.04)
  • kdevelop-php (php-plugin)
  • kdevelop-php-docs (optional, recommended)
  • kdevelop-l10n (localisation, recommended)
  • kdevelop-php-l10n (localisation, recommended)
  • php5-xdebug
then, unfortunately not commonly available as binary packages:
  • kdev-xdebug
  • kdev-php-formatter (optional)
Everything mentioned in the 1st list is usually available through the package manager of most distros, I will not further explain how to get these installed, but rather outline the steps needed to get the plugins installed that have to be built from source (usually). First step is to get everything which is needed to build KDE source packages, namely git, g++, cmake, kde development librarys and so on. For most distros, a good start is usually this . Then, general advice on how to build KDE packages from source is also on KDE techbase . A short howto (slightly outdated, e.g. executescript and executebrowser are now parts of kdevelop base, no more extra install needed) for building kdev-xdebug is available on Niko Sam’s site . This is also what I used as a a starting point. But, as this howto is a bit short (not every step obvious for n00b’s 😀 ), and, as not everything went quite well (as usual 😀 ) I decided to outline here a bit more in detail what I did, what went wrong and how I got around the problems to get it to work, finally. Maybe this will also help others… So, let’s start:
  1. get the source:
    mkdir ~/kdevplugins (or any other suitable location)
    cd ~/kdevplugins
    git clone git://anongit.kde.org/kdev-xdebug
    cd kdev-xdebug
    git branch -a (this shows which branches are there, choose the correct one: 1.5 is for kdevelop 4.5.x, 1.4 for kdevelop 4.4.x)
    git checkout remotes/origin/1.5 (use correct branch here, or master for the latest and greatest)
  2. build:
    mkdir build && cd build
    cmake .. (in case cmake complains about missing dependencies, install these and start over)
    make
  3. install:
    sudo make install
    kbuildsycoca4
  4. check kdevelop plugins if kdev-xdebug is there:
  5. enjoy 😀
Ok, at least, that’s the way it is supposed to work 😉 For me, there was the problem, that although every step obove (except 5.) succeeded, I was not able to get the debugger running, see this thread in the kdevelop mailinglist. After some investigation, and thanks to the help of Niko, the xdebug plugin developer, I succeeded to get it to run, heureka. The culprit was the installed php5-fpm extension (which makes no sense, IMHO, on a desktop computer) which blocked port 9000 on localhost, which in turn is needed by xdebug. As can be seen on the list, Niko has meanwhile added a comprehensive error message in the plugin (git master) in case anyone else is affected by this problem. Conclusion: finally, the plugin works as expected, an invaluable help when developing php code that is a bit more sophisticated than just calling phpinfo() 😀 So, no need anymore for Quanta/Gubed, in this respect. And not to forget, there are meanwhile other php/web dev related kdevelop plugins, namely:
  • kdev-upload
  • kdev-php-formatter
  • kdev-css
  • kdev-xml
which are still experimental, but promise to even further qualify Kdevelop as a real replacement for good old Quanta. (From these mentioned, I’m using kdev-upload on a regular basis, and it works so far as expected, just not deleting files on the server which have been removed locally, but that’s a minor issue, IMHO). Additional note: a simple debian package (built with checkinstall, so no real dependency checks..) can be found here: kdev-xdebug_20140201-1_i386.deb – simply download and install with ’sudo dpkg –install kdev-xdebug_20140201-1_i386.deb‘. Be warned: this is only tested on Kubuntu 12.04 with kdevelop 4.5.1 installed in default locations, including mentioned php stuff !

KDE 4.9.2 – another approach

So, after having been fed up with akonadi/nepomuk Disaster in previous KDE4 Versions (and hence switched to Trinity) I decided to give it another try.

This was mainly triggered by recent, rather positive feedback in KDE mailinglists, which indicated, things could have been significantly improved. So I bit the bullet and installed Kubuntu 12.04 with KDE 4.9.2 (from backports PPA) alongside my favourite Debian/Trinity on my main Desktop, which is a rather weak peace of Hardware (Dual core Intel Atom, 1.7 MHz CPU, 1 GB RAM, Intel GMA3150 Graphics), but more than ok with Trinity, in fact: this flies 😀 And now, KDE 4.9.2: Installation went rather unspectacular, Hardware fully recognized, Login/Desktop came up as expected, with default settings. This included a rather conservative screen resolution (1024×768) which looked really ugly :-/ Instantly changed via Systemsettings, much better… Then, as a surprise, there was no konqueror, but rekonq as Browser and Dolphin as Filemanager, instead. Seems to be Kubuntu specific thing, though, so I installed Konqueror as a next step. Then started Kontact to check if the KDE-PIM-mess finally has come to an end 😀 . And, yes, everything important (email, kontacts, newsfeeds) worked more or less ‚out-of-the-box‘ after configuration/Data Import. Even virtuoso (Backend for Nepomuk) worked directly (which was never the case for me with previous KDE Versions). Then I decided to switch to the sqlite Backend for Akonadi (instead of running the default mysql Server, which is Bloat/Overkill, IMHO). Seemed to be just 1 click away in Systemsettings, but after that, Akonadi stopped running and gave a bunch of error messages (missing Drivers etc…). Turned out I had to install package akonadi-backend-sqlite, which was not obvious, though. Then I proceeded with Installation of some additional software like blogilo (which is a nice Blogging Program, currently used to write this Blog entry), and, out of curiosity, the KDE Office suite: Calligra. This one seems slowly to reach a usable state, its predecessor, Koffice (KDE4 Version) had several times corrupted my Data Files, which was another reason to stick with Koffice 1.6 (Trinity Version), which is simple, but reliable. What else ?
  • Some minor annoyances, so far:
  • Kmail (as well as other Programs) keep asking for access to kwallet at startup, despite having activated ‚always grant access‘
  • Yakuake doesn’t save settings (screen width)
  • everything (especially switching Windows/Desktops) is not as snappy as in Trinity, as expected, but acceptable, even on this weak Machine.
On the other Hand, some well appreciated Improvements, like:
  • Nice new Applications (Blogilo, Gwenview, improved Kate+Plugins, Calligra ?)
  • Handy Plugin Concept for PIM-Enhancements (akonadi-kde-resource-googledata..)
  • Flexible Aggregations for Mail-Overview (kmail)
  • Much improved Konqueror (compared to Trinity Version) w.r. to Page-Rendering/Javascript etc.
So, ATM, I will not yet draw a conclusion, as I still have to explore/investigate much (Activities, new Apps, Configurations, Akonadi Data Handling/Backup..), but it is obvious, that KDE4, after more than 4 years, now has finally reached a usable State, at least, on not too old Hardware (I still have 2 Machines on which I will not even try once more a KDE4 Install). To be continued…

Thoughts about KDE/trinity…

First of all, this might seem to be mostly a rant about KDE, but I think it is not (at least partly 🙂 ).
But it is, for sure, criticism, and, of course, my very personal opinion (I am not in any way a representative of any of the mentioned projects, just a user/contributor – more or less).
So, what’s going on in the KDE world ?
In short, these are the most important activities:
In 2008, KDE4 was started as the successor to KDE 3.5, with massive changes to the underlying software stack, not just porting to qt4.
First to mention, the new desktop shell: plasma, with radical changes: no more ‚Desktop‘ with Program icons, Plasmoids instead of traditional Applications, new control widgets (‚Cashew‘) and so on…
But with all these changes, and their problems (which are quite normal in the development cycle of huge projects), it was more and more obvious that many users would not want to follow the directions given by the developers anymore.
To sum it up, there is now a clear demand for a lightweight, simple Desktop, based on technology already known (qt libs), but without the mandatory need to have more or less powerful hardware, and (at least) the option to just not install/run memory/power consuming services simply to be able to run a web browser or an email client.
And, of course, there are also (few) developers who share this opinion, and thus, we can now find at least 2 projects to follow the mentioned goals:
trinity and razor-qt, both taking a different approach, however:
while trinity stands in the direct heritage of KDE 3.5, trying to keep as much of this experience alive as possible
(including the underlying qt3 framework), razor-qt follows another paradigm:
provide a clean, slim desktop based on qt4, following widely accepted standards (xdg) without all the load something like
plasma/akonadi/nepomuk etc. bring in addition.
This doesn’t include a native set of applications, however – it is up to the user to decide which ones to add (and thus, which additional dependencies/frameworks to pull in – might end up with nearly a complete KDE4 desktop installed, though 😀 ).
The stunning fact, with these projects, is that for the first time in the KDE history, there are now ‚forks‘ which
aim to users who are not satisfied with the current direction of the project.
The interesting thing, now, is how these 2 projects are perceived in the KDE(4) mainstream, especially developers.
With razor-qt, there seems to be not very much flame-wars, at least not widely visible.
As for trinity, see e.g. this:
Pro-Linux Article (german).
KDE4 developers however, seem to be rather upset, that anyone ‚dares‘ to fork what they, appearantly, have dropped back then in 2008 (when KDE4 still was far from beeing usable in any respect) as if it were some piece of radioactive plutonium or thelike.
Anyone interested in this subject may just read Martin Grässlins articles/blogs:
Freies Magazin Article (german)
the-grass-has-always-been-greener-on-the-other-side-of-the-fence
having-a-look-at-the-oldnew-desktop-environments
or also the trinity list archives:
trinity-devel.pearsoncomputing.net (threads ‚trinity coverage‘, ‚poll‘ …)
nwhere also Aaron Seigo’s statements can be found, who obviously avoids writing something on the subject in his own blogs – looks like he wants to avoid any publicity on trinity, presumably.
So, while I do not want to comment on the more technical argumentations in the cited sources, it seems to me that the KDE4 developers just can’t stand nor tolerate the fact that there are still users (and developers!) who prefer that what KDE3 offered: a fast, snappy Desktop (even on older Hardware) with a complete (though, with some respect, outdated) set of applications, without all the recently added ‚bloat‘ 😉 .
As a conclusion, simply time will tell wether trinity and/or razor-qt will survive (I personally hope so), and what direction KDE4 will go.