There are plenty of positive Soul Medic reviews, since you can read those to learn about the great parts of the theme (for example the beautiful clean responsive design) I’ll stick to the parts that people don’t list in their reviews. 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 so I decided to publish these infos on this blog.

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

1. Soul Medic WordPress Theme has CSS issues with all browsers but Firefox

As you can see on the screenshot the Soul Medic style sheets create buggy sub menus and mega menus. There’s a thin white line in between the sub navigation and the navigation bar. 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

What really hurts the usablilty and comfort of a wordpress site is the Visual Editor (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’s also plenty of other smaller issues. For example the left sided Buddha Panel (the themes admin panel) had css issue that lead to the admin menu content moving below the navigation instead of beside it. I’ll try to provide you with a more detailed list soon.


If you are still interessted in this theme, you can buy it here:

Note: The link is a referral link. You can copy the URL without the “?ref=mako1234567” part if you think that I should not earn something for this review.

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. It took me a lot of testing and debugging, but finally I figured out that the follow line caused the problem:

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

WordPress behaves differently now. Before the 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, gives no error message and also inserts nothing.

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

First install Visual Studio Express 2012: [german] [english]

Then download the latest version of cocos2d-x: [Currently: Cocos2d-x -> Download v3.3 (latest)]

Unpack cocos2d-x to the root folder of a fast drive with enough space:

Unpacking cocos2d-x to a local windows 7 folder

Unpacking cocos2d-x to a local windows 7 folder

Now open the Cocos2D-X Visual Studio Express project:

Open the Cocos2d-x Visual Studio 2012 project

Open the Cocos2d-x Visual Studio 2012 project

Confirm that you trust the project even though it’s from a “non trusty source”. After that you should see multiple entries listed in the project explorer. Right click the “cpp-tests” entry and select “Set as StartUp Project”:

Cocos2D-X Set cpp-test as Start Up project

Cocos2D-X Set cpp-test as Start Up project

Now hit the compile button:

Cocos2D-X Visual Studio Compile Button

Cocos2D-X Visual Studio Compile Button

You will most likely get an error about outdated projects, just hit “yes” to confirm you want to update them. The Visual Studio Output will start to show progress updates along several warnings that can be ignored. As soon as the compilation is done, the tests application will be started in a new window:

Cocos2D-X Visual Studio Cpp Tests Running

Cocos2D-X Visual Studio Cpp Tests Running

That’s it, you just compiled your first Cocos2D-X application.

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