Sound Medic is a clean, professional looking 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 the theme has. I also posted a short version of this on Themeforest, but sadly the Soul Medic support decided to censor the review, leaving potential buyers in the dark.

So what do the other reviews hide? There are two major problems with the Soul Medic wordpress theme right now – and multiple smaller issues. I’ll start with the main issues.

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 a bugged sub menus and broken mega menus. The white line in between the sub navigation and the navigation bar is the problem. As soon as you move your mouse down to the sub menu the sub menu might close, because hovering the mouse over the white line makes the menu close.

This bug has been reported over 30 days ago, 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’s a screenshot displaying the problem on the official soul medic demo (the demo has been fixed with patch mentioned above after my report):


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:

Note: The link is a referral link. Copy the URL without the “?ref=mako1234567” part if you think that this review did not help you.

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.

If you use the Fat Free Framework to deliver javascript, you need to set the contents mime type to ‘application/javascript’ (‘text/javascript for IE 8 and previous versions).

You tried to use PHPs header() function to do so but the header type still is wrong.

How not to set the headers mime type for F3 Views

header('Content-Type: application/javascript');
echo View::instance()->render('profile_js.js');

How to set the header mime type using Fat Free Framework

The reason for the wrong mime type most likely is the script calling View->render() which has a single parameter in most but examples but also has an optional second parameter to pass the mime type. This parameter defaults to text/html, the call will overwrite the previously set header. If you set the second parameter the mime type will be correctly output:

echo View::instance()->render('profile_js.js','application/javascript');

Officials documentation on setting the header mime type in Fat Free Framework