Skip to content

English plugin dev 2 4

Charlie Gorichanaz edited this page Nov 5, 2015 · 9 revisions

Plugin Debugging

It is nice that everything works just as you have intended, right?
If only. Now lets see how to deal with the inevitable bugs

Debug Testing

We are TDD guys, right? when we see a bug, first thing to do it to write a test that will fail because of this bug.

Some recurring problems for example:

  • Errors that occurs when running the tests
    • A module is missing
      • Either add the module that you forgot to write, or correct 00-compile.t, so it won’t test file that should not exist
    • The code is referring an incorrect location
      • for example, you copied code from MyPlugin06, and forgot to change all the places to you new plugin’s name
    • Syntax Error
      • Modify the code based on this error
  • Does not display the correct information, or the plugin is not multilingual
    • Amend config.yaml
    • Verify that L10N.pm, L10N/en_us.pm and L10N/ja.pm are in the correct location
    • Similarly, verify that the content is correct. For example, if in the L10N file it is written: "Test Code" => ”テストコード", and in config.yaml it is written “Test Codes”, then the text will not be translated

Debug logging: using doLog (Perl)

If MT is installed on your local computer, you can use print STDERR to spill information to the webserver’s error log. Otherwise, it is possible to use MT’s own logging to provide information. For doing that easily, define a function named doLog:

sub doLog {
    my ($msg, $class) = @_;
    return unless defined($msg);

    require MT::Log;
    my $log = new MT::Log;
    $log->message($msg);
    $log->level(MT::Log::DEBUG());
    $log->class($class) if $class;
    $log->save or die $log->errstr;
}
  • $msg : Message to write in the log
  • level : Log level, can be one of:
MT::Log::INFO() 1
MT::Log::WARNING() 2
MT::Log::ERROR() 4
MT::Log::SECURITY() 8
MT::Log::DEBUG() 16
  • $class : Error class.
    Starting MT5.1, you can set the object type that this error message belongs to:
author 5.1〜
blog 5.1〜
website 5.1〜
entry
page 5.1〜
category 5.1〜
folder 5.1〜
tag 5.1〜
comment
ping
search
asset 5.1〜
template 5.1〜
theme 5.1〜
publish
system 5.1〜(旧 ログ)

Calling the doLog function:

  • Simple example: just output a message
doLog($some_msg_or_value);
  • Calling with class: making it easier to find it later in the logs. (by using filtering)
doLog($some_msg_or_value, 'entry');
  • Dumping data using Data::Dumper into the logs
    This will dump a hierarchical data into the logs, in somewhat readable form.
    As it produce a log of data, please use with care.
use Data::Dumper;
doLog(Dumper($MT_Blog_Object));

All these will save data to the system log, where it can be read and used.
After debugging, please be sure to remove these debug lines.

Using the Debug Mode

In “System Overview”→“Settings”→“General”, there is a “Debug Mode” option.
Activating this will present to you any warning message that was produced while viewing the screen, and also a debug panel popping out from the right.
Possible flags:

0 Debug mode disabled
1 Warning messages and page rendering time
2 stack trace
4 SQL queries and timing
8 List of points that took more then quarter a second to process
128 Dump response to STDERR

This variable is bit-flag style, meaning that if you are interested only in stack-trace and SQL queries, you should set this variable to 2+4=6.

The debug panel popping on the right is useful to inspecting SQL queries and cache hit/miss, HTTP headers and such

Using the Perl Debugger

It is possible to use the Perl internal debugger to debug MT. There is a blog post about it, but in Japanese.
Still, if you ignore the Japanese around the code, it is still useful. You should just know that $DB::single=1 (not “signal”) statement is telling the debugger to stop the program execution and move to stepping mode. (so put it in the right place)
The rest is just configuring the TTY, (which is your command line box) Apache and MT to talk together.

Movable Type のプラグインをperl debuggerでデバッグする(エムロジック放課後プロジェクト)

Starting the Perl debugger manually

Use the following commands:

$ cd $MT_DIR
$ perl -d mt.cgi 1>/dev/null 2>&1

Loading DB routines from perl5db.pl version 1.28
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

  DB<1> 

Then you can play with MT – for example loading and inspecting Website #1:

  DB<1> $site = MT::Website->load(1);
  DB<2> x $site
0  MT::Website=HASH(0xa3f8294)
   '__core_final_post_load_mark' => 1
   '__is_stored' => 1
   '__meta' => MT::Meta::Proxy=HASH(0xa3f7dc0)
      '__pkeys' => HASH(0xa3f83e4)
         'blog_id' => 1
      'pkg' => 'MT::Website'
   '__triggers' => HASH(0xa3f821c)
        empty hash
   '_class_trigger_results' => ARRAY(0xa3f8270)
      0  ARRAY(0xa3f82dc)
         0  MT::Website=HASH(0xa3f8294)
            -> REUSED_ADDRESS
      1  ARRAY(0xa3f8348)
           empty array
      2  ARRAY(0xa3f8024)
         0  ''
   'column_values' => HASH(0xa3f8324)
      'allow_anon_comments' => undef
      'allow_comment_html' => 1
      'allow_commenter_regist' => 1
      'allow_comments_default' => 1
      'allow_pings' => 1
... snip ...

Here we ensure that the correct data is loaded. other uses to the debugger are not discussed here

Debugging PHP plugin

The only available way to debug a PHP plugin is using a printf, to add debug info to the page

Summery

Remember, what all bugs have in common is that you created them, and they passed compiler check and your tests.
While tests certainly reduce the likelihood of bugs in released code, so you should probably write some, but the coverage in never 100% and then good luck debugging.

Still, debugging is a skill, and hitting things randomally won’t get you very far. Try to think where it can be, verify that variable values are what you think that should be, and follow the code execution until you find the cause.

Good luck.

Navigation

Prev:Developing Conditional Tags Plugins << Index >> Next:Plugin Configuration

Clone this wiki locally