Dirty Motherfucking Blog » php

Introducing SDML

gencha — Wed, 15 Sep 2010 19:50:35 +0000

On the server-backend of a project I am currently working on, I was also faced with the task of installation and setup procedures for said backend software. It’s a PHP application with a MySQL database behind it.

I was looking for a simple solution to have a PHP script that would set up the database for me. Using SQL export/import files is just a pain in the ass. They’re just quite verbose. So usually I would construct the database in a GUI and then export the .sql file and later re-import it. One positive aspect of this was, that the .sql file could be put under version control.

But I wasn’t satisfied. So I came up with my own solution to the issue and designed a language with a few keywords and even less parameters, which would allow me to model exactly the database as it was at that point.

SDML is really only intended to be used with InnoDB tables (because of the way foreign key constraints are used) and it always defaults to UTF8 usage. And there is no support for user-defined triggers, function or stored procedures. Given MySQL and PHP, I don’t like to use functions and SPs in the database anymore. Which is the reason no support is planned in SDML.
However, SDML does automatically create triggers for certain constructs that I use quite often (creating/updating timestamp).

Documentation is quite lacking right now, as, well, I literally just released it. You can find it on this Google Code site.

TL;DR: I wrote a simple language for fast database prototyping – Simple Database Markup Language.

Passing SOAP faults from NuSoap to C#

gencha — Tue, 27 Apr 2010 19:59:06 +0000

I am currently implementing a SOAP interface for a PHP application I am working on. The built-in SOAP support in PHP didn’t really provide everything I needed (namely WSDL generation), so I went with NuSoap.
After a lot of pain trying to get a WSDL out of it, that Visual Studio would consume, and correctly parse the SOAP messages I return, I came along the next big issue today.
Whenever I tried to pass a fault from the server to my C# application, I would receive a nasty exception:

Server returned an invalid SOAP Fault. Please see InnerException for more details.

Ok, so let’s look at that InnerException:

Element ‘faultstring’ with namespace name ” was not found. Line 6, position 126.

What? No “faultstring” element? Impossible!
After double-checking my code for obvious errors and confirming with SoapUI that the “faultstring” element was indeed present, I started looking for the source of the issue. First I checked the nusoap_fault source, if there was anything weird in there that might confuse the CLR. But it seemed fine.

So I was sure the problem must be in the .Net libraries. I went on to decompile the binaries that are in use when making SOAP requests (namely System.ServiceModel). The actual issue was in System.ServiceModel.Channels.ReceivedFault.CreateFault11(). That function expects the elements of a SOAP fault’s body to be in a precise order! If the order is anything else than what it expects, it will throw the exception mentioned above.

I did not take the time to check whether this behavior is actually defined by the SOAP definition (although I highly doubt it). I just went on to extend the NuSoap classes to fix the issue. And here they are:

NuSoapServer.php:

debug_flag ) {
        $faultdetail = $this->getDebug();
      }
      $this->fault = new NuSoapFault( $faultcode, $faultactor, $faultstring, $faultdetail );
      $this->fault->soap_defencoding = $this->soap_defencoding;
    }

  }
?>

NuSoapFault.php:

namespaces as $k => $v ) {
        $ns_string .= "\n  xmlns:$k=\"$v\"";
      }
      $return_msg =
        'soap_defencoding . '"?>' .
        '\n" .
          '' .
            '' .
              $this->serialize_val( $this->faultcode,   'faultcode'   ) .
              $this->serialize_val( $this->faultstring, 'faultstring' ) .
              $this->serialize_val( $this->faultactor,  'faultactor'  ) .
              $this->serialize_val( $this->faultdetail, 'detail'      ) .
            '' .
          '' .
        '';
      return $return_msg;
    }

  }
?>

So now in my actual code I don’t use nusoap_server anymore, but my own NuSoapServer. And now everything works fine.

Flash Player version in AWStats – Revised

gencha — Thu, 20 Nov 2008 10:46:43 +0000

My first implementation of this idea may have been sufficient for general use. For inclusion in WordPress however it was problematic at best.
Now that I have revised (and tested) it, I thought I’d share this updated WordPress plugin.


	
	
	';
}
?>

In this version I put the JavaScript code inline. Although I’m not a big fan of that, it’s reasonable in this case and I have all the code in one place. This made it easier to fix the second bug. Which was that the whole concept only worked on the main page. On other pages the browser couldn’t find the flash_version.php file. Which resulted in nasty 404 errors. Now I can simply put the blogs base path into the JavaScript code and everything is well.

Including Flash Player version in AWStats

gencha — Wed, 12 Nov 2008 11:22:09 +0000

I was interested in what Flash Player version people are using when visiting my site. So i looked around the web for a solution including AWStats. At first i was out of luck until i noticed that AWStats has a discussion forum on sourceforge as well.
Someone there came up with a solution which was almost perfect for me.

First of all you’re gonna want to put this in your awstats config file for your site:

ExtraSectionName1="Flash Player Version"
ExtraSectionCodeFilter1="200 304"
ExtraSectionCondition1="URL,\/flash_player_version\.php"
ExtraSectionFirstColumnTitle1="Version"
ExtraSectionFirstColumnValues1="QUERY_STRING,version=([^&]+)"
ExtraSectionFirstColumnFormat1="%s"
ExtraSectionStatTypes1=PL
ExtraSectionAddAverageRow1=0
ExtraSectionAddSumRow1=1
MaxNbOfExtra1=100
MinHitExtra1=1

Note that i made some slight adjustments to some strings compared to the original version.
Now you need to add some JavaScript to make appropriate URL requests that AWStats can read from.
Note that this is the original code, not the one i finally ended up with.

As i did not want to just jam this into my theme files, i wrote a little WordPress plugin to do the above task.

I took some small bits from the KML Flash Embed plugin. This will include the appropriate JavaScript files in your blog. Obviously, if you’re not using WordPress, this is of no use to you. You can just directly include SWFObject in the head section of your site.

Now the important bit is the JavaScript file that actually performs the URL request which AWStats will later see.

window.onload = function() {
	var version = deconcept.SWFObjectUtil.getPlayerVersion();
	if( document.getElementById && version["major"] > 0 ) {
		var flash_version = version['major'] +"."+ version['minor'] +"."+ version['rev'];
		document.getElementById("flashversion").innerHTML = "";
	}
}

Now the only thing that is left is that you include an empty div tag with the id “flashversion” somewhere in your site. Now THIS i did just jam into my theme :P
Although i am sure there is some hook i can use in the WordPress plugin architecture. But i’m lazy. So there you have it.