Textpattern CMS

#1 2009-09-20 22:03:03

gerhard

Plugin Author

From: London, UK

Registered: 2005-06-29

Posts: 409

Website

Improved zem_tpl

I was using the updated zem_tpl for TXP 4.2.0 for the new glz_custom_fields and was getting annoyed with how the current zem_tpl works. If you’re using a similar approach to mine when it comes to developing TXP plugins, you’ll find this useful.

For those wanting to dive staight into the code, updated zem_tpl.

Building TXP plugins, my way:

1. Install a vanilla TXP instance

2. Define a plugins directory in Admin > Preferences > Advanced

3. In the above plugins directory, create a symlink (shortcut) to your plugin’s code

This is where the my updated zem_tpl comes into play. I am assuming that you have your plugin in a separate folder (maybe it’s a repository…), let’s say my_plugin. This folder might look like this:

.
|-- HISTORY
|-- TODO
|-- my_plugin-0.1.gz.txt
|-- my_plugin.php
|-- my_plugin_code.php
|-- my_plugin_help.html

Your help is kept separately and you can write it in raw HTML (handy for previewing it) and your plugin code is also separate, just right for symlinking it into TXP’s plugins folder and testing it as you add/tweak functionality.

4. When you’re done, php my_plugin.php > my_plugin-0.2.gz.txt

Any insight into how other developers are rolling would be greatly welcome!

---

Twitter | Github

#2 2009-09-20 23:24:38

redbot

Plugin Author

Registered: 2006-02-14

Posts: 1,410

Re: Improved zem_tpl

Hi gerhard,
I use ied_plugin_composer, which is now mantained by Bloke. I find it very useful both for writing and for modifying installed plugins.

---

Some Txp stuff

#3 2009-09-20 23:32:18

jm

Plugin Author

From: Missoula, MT

Registered: 2005-11-27

Posts: 1,746

Website

Re: Improved zem_tpl

gerhard wrote:

Any insight into how other developers are rolling would be greatly welcome!

I wrote a different style of compiler awhile ago. The main differences from zem’s compiler are a) metadata is declared in a code comment and b) plugin code can be broken up into multiple source files:

<?php
/**
   * @name         jmd_example
   * @description  An example plugin.
   * @author       Jon-Michael Deldin
   * @author_uri   http://jmdeldin.com
   * @type         [0-3]
   * @order        [0-9]
   */

function my_plugin()
{
    // throw JS from my_plugin.js into a variable
    $js = <<<EOF
//inc <my_plugin.js>
EOF;

    // ...
}

---

What? My name is… | GitHub

#4 2009-09-21 00:23:16

gerhard

Plugin Author

From: London, UK

Registered: 2005-06-29

Posts: 409

Website

Re: Improved zem_tpl

jm wrote:

I wrote a different style of compiler awhile ago.

That is exactly what I was trying to achieve with my quick changes to zem_tpl. Your txpc is better since my changes don’t currently handle required files. Thanks Jon-Michael!

Last edited by gerhard (2009-09-21 00:23:53)

---

Twitter | Github

#5 2009-09-21 02:28:51

jm

Plugin Author

From: Missoula, MT

Registered: 2005-11-27

Posts: 1,746

Website

Re: Improved zem_tpl

Glad you like it! I need to update the documentation still, but hopefully it’ll work for now.

Last edited by jm (2009-09-21 02:29:01)

---

What? My name is… | GitHub

#6 2009-09-21 12:25:10

ruud

Developer Emeritus

From: a galaxy far far away

Registered: 2006-06-04

Posts: 5,068

Website

Re: Improved zem_tpl

For each plugin I have a single file, just like zem_example_plugin.php.
When I offer the plugin publicly, I upload it to my website, where I have a slightly modified zem_tpl.php installed which allows visitors to get a compressed or non-compressed plugin, view the plugin code and view the documentation… all based on that single plugin file.

#7 2009-09-22 05:56:10

gerhard

Plugin Author

From: London, UK

Registered: 2005-06-29

Posts: 409

Website

Re: Improved zem_tpl

txpc looked good, but it didn’t give me instant gratification. I couldn’t work in separate php files, preview my changes to the plugin in TXP and then just package it once my work was done. I have modified my zem_tpl to fetch the content of all files called via include_once upon packaging.

I didn’t account for 2 levels or more of include_once (e.g. when an included file has another include_once), but I don’t need it just yet. At the end of the day, it’s only a matter of looping through the matches array, so it shouldn’t be a biggie.

Last edited by gerhard (2009-09-22 15:37:14)

---

Twitter | Github

#8 2009-09-22 15:15:59

jm

Plugin Author

From: Missoula, MT

Registered: 2005-11-27

Posts: 1,746

Website

Re: Improved zem_tpl

gerhard wrote:

txpc looked good, but it didn’t give me instant gratification.

You could have written a wrapper script in your cache:

<?php
// location: cache/wrapper.php
include 'path/to/txpc.php';
$myPlugin = new TXPC('path/to/primary/src.php', './', '../releases');

Although I normally just do \m in Vim to link and compile the plugin when I’m ready to preview.

I didn’t account for 2 levels or more of include_once (e.g. when an included file has another include_once), but I don’t need it just yet.

Neither did I because it’s adding unnecessary complexity – I prefer having one file that includes all of my other source files for compiling (it’s a nice pattern for longer LaTeX docs too).

Last edited by jm (2009-09-22 15:17:00)

---

What? My name is… | GitHub