Sound Medic is a professional clean wordpress theme. There are plenty of positive reviews for it, read them to find out about the great parts of theme, this post is about the problems that I ran into when installing it on a clients blog. I also posted a short version of this on Themeforest, but the Soul Medic support decided to censor the review, leaving potential buyers in the dark. Thus I leave it here.

There are two major problems with the Soul Medic wordpress theme right now – and multiple smaller issues. I’ll just talk about the main issues, since I was able to work around the smallers issues easily.

1. Soul Medic WordPress Theme has CSS errors with all modern browsers except on Firefox

As you can see on the screenshot the Soul Medic style sheets cause broken sub and mega menus. The white line in between the sub navigation and the navigation bar blocks access to the sub menu entries since as soon as you move your mouse down to the sub menu the sub menu closes, because hovering the mouse over the white line makes the menu close. Only fast mouse movements allow to bypass the gap fast enough to keep the submenu open.

This bug has been reported over 30 days ago (18.12.2015 – over 6 months now) , the official theme files still haven’t been fixed. There have been 2 updates for the theme in that time frame, but none fixed this issue. The Soul Medic theme support provided me with two style sheet files (styles.css and response.css) but didn’t fix their release files. Now with every update I have to overwrite those two style sheet files which most likely will cause problems in the future, since I also have to overwrite all future changes to those files.

Here you can read about the report:

The link also contains the (OUTDATED!) css files required to run the theme on most modern browsers.

Here’s a screenshot displaying the problem on the official soul medic demo. That demo has been fixed with patch mentioned above after my report, so shouldn’t show the behaviour.

soul medic wordpress theme review submenu css bug wordpress history problem

Still the same problem after nearly a full year

2. The Soul Medic WordPress Theme visual editor breaks on a page breaks wordpress functionality like Revisions or the wordpress editor

A bug that hurts the usablilty and comfort of a wordpress site is the Visual Editor (aka Soul Medic Page Builder) sychronisation bug. As soon as you enable the page builder for a page you loose wordpress’s revision system for it. You can revert to an older revision but Page Builder will still show the old unchanged content. I was looking at this because of a user report and after some research I figured out that the Soul Medic Page Builder is not able to read the wordpress content from the database. It saves its own data at some other place and there’s no way to sync wordpress content to the page builder. That also means that you can not use the wordpress editor to do small changes. Because those changes will not show up in the Page builder.

This bug has been reported 30 days ago, I provided the Soul Medic support with a test and details but they don’t seem to plan to fix it.

There are also other smaller issues. For example the left sided Buddha Panel (the Soul Medic admin panel) has a css issue that leads to the admin menu content being placed below the navigation panel instead of beside it.

If you are not scared of patching file manually and interessted in this otherwise nice theme, you can buy it here:


Soul Medic Review – Update 24.05.2016

It’s been nearly a full year since I reported the sub menu problem and checking the latest version showed that the Soul Medic developers still didn’t fix it. I fear this theme never will get fixed, even the official demo is broken once again. No idea why the developer deny to fix their theme, but right now I can’t recommend it at all.

Since I couldn’t find any documentation on what param types FlixlUIs xml importer supports I did a quick check in the Flixel Addons sources.
Here’s the relevant part in FlixelUI.hx (line 2731, function getParams):

switch(type) {
    case "string": params.push(new String(param.att.value));
    case "int": params.push(Std.parseInt(param.att.value));
    case "float": params.push(Std.parseFloat(param.att.value));
    case "color", "hex":params.push(U.parseHex(param.att.value, true));

So the types are:

  • string
  • int
  • float
  • color

A quick warning: Right now it’s dangerous to use more then one param inside an xml file because Haxeflixel sometimes reverses the array for no apparent reason. If you need to pass more then one parameter, I suggest the string type and serialized data.

I just had a clients wordpress website die on him after updating to wordpress 4.2.1. After some testing/debugging I finally noticed that the following line made wordpress die silently:

$wpdb->insert('videos', array(...), array(...));

WordPress’s behavious changed in 4.21. Before this update, wordpress truncated strings if a database text field (varchar) was too small for the text to fit. Now $wpdb->insert() doesn’t do anything when the string is too long, it gives no error message and also doesn’t inserts anything.

My fix was to manually truncate the strings with

Of course I also could have increased the columns varchar size, but in this specific case only the first 100 characters were needed.


1st step: Generate the private key

D:\work\projects\ios_dev_flash>c:\Users\mako\Downloads\openssl-0.9.8s-x64_86-64\openssl.exe genrsa -out mykey.key 2048
 Loading 'screen' into random state - done
 Generating RSA private key, 2048 bit long modulus
 e is 65537 (0x10001)


2nd step: Generate a certificate signing request for Apples IOS Developer Center

D:\work\projects\ios_dev_flash>c:\Users\mako\Downloads\openssl-0.9.8s-x64_86-win64\openssl.exe req -config D:\xampp\apache\bin\openssl.cnf -new -
key mykey.key -out CertificateSigningRequest.certSigningRequest  -subj "/, CN=Malte Koehrer, C=DE"
Loading 'screen' into random state - done

Note: Only use ASCII characters for the Signing request infos. Special characters like german Umlaute will give you a “4200:error:0D07A07C:asn1 encoding routines:ASN1_mbstring_ncopy:illegal characters:.\crypto\asn1\a_mbstr.c:162:” error.

3rd step: Uploading the certification signing request at the IOS Developer site

Follow these steps:


Confirm the next screen, then click the “Chose File” button, select the certificate signing request and hit the upload button. Now you can press the “Generate” button to generate the certificate.

4th step: Downloading the certificate

Press download here to download the file “ios_distribution.cer”:


5th step: Converting the .cer certificate to a PEM one

D:\work\projects\ios_dev_flash>c:\Users\mako\Downloads\openssl-0.9.8s-x64_86-win64\openssl.exe x509 -in ios_distribution.cer -inform DER -out developer_identity.pem -outform PEM

6th step: Combine the private key (.pem) and the certificate (.cer) into a .p12 file

D:\work\projects\ios_dev_flash>c:\Users\mako\Downloads\openssl-0.9.8s-x64_86-win64\openssl.exe pkcs12 -export -inkey mykey.key -in developer_identity.pem -out iphone_dev.p12
Loading 'screen' into random state - done
Enter Export Password:
Verifying - Enter Export Password:

That’s it, you now should be able to use the .p12 file along with your mobileprovision file.

One of my projects which was based on a .hxp build file caused a problem and stopped compiling with the previous version of lime tools because there were changes in the latest haxelib versions.

The error message was:

D:\work\projects\[private]\project>haxelib run openfl build flash
Class not found : project.HXProject

Joshua Grannik explained that the project.* name space was moved to lime.project.* but a first test didn’t give positive results:

import lime.project.HXProject;

D:\work\projects\[private]\project>haxelib run openfl build windows
Class not found : project.HXProject

But with todays haxelib upgrade a new version of lime tools that worked this way, has been release. Now lime.project.* was avaiable.

A simple

import lime.project.*;

fixed it all and the project was compiling again

Enabling hxcpp debugging in a haxe or openfl project is easy if you use the standard xml project file. It’s also no rocket science to activate it in a .hxp file, just undocumented.

Here’s a quick example on how to enable the haxe debugger:

haxelibs.push(new Haxelib("hxcpp"));
haxeflags.push("-D HXCPP_DEBUGGER");
haxelibs.push(new Haxelib("debugger"));
haxeflags.push ("-debug");

Tested on Windows but should work on any platform or system that’s using hxcpp.