ied_plugin_composer - new plugins never came that easy

azw · 2009-02-22 03:18:50

Hmm. What about the instances in which I upload a php template and try to save it in composer but it won’t save it?

Yep. That could still be the fact that the status variable (which I can’t fill in) is null.

<b>Warning</b>:  Incorrect integer value: '' for column 'status' at row 1
update txp_plugin set name='azw_test2',
				status = '',
				type = '0',
.... and so on.

Bloke · 2009-02-22 13:09:59

Gocom / azw

Thanks for the pointers/testing; I didn’t know that. The SQL statements in the code are pretty much the same as they were back when Yura coded the thing up and I guess things have moved on a tad. I’ll make sure any not null fields are declared in the insert statements in the next rev and also look into the feasibility of being able to directly start a new plugin in the plugin_cache_dir. Watch this space.

Bloke · 2009-02-23 13:14:55

v0.82 | compressed released.

Adds the ability to directly create plugins in the cache directory by specifying the plugin name with .php appended to it in the Create new plugin box (thanks azw)
Is more aware of database column ‘types’ so should now not complain when using MySQL in strict mode (thanks Gocom / azw)
Fix for huge documentation files (*cough cough guilty*) so they don’t overspill the allocated size
Major internal rewrite for template generation so keeping the standard template up-to-date is easier for me

azw, please check the new functionality with your setup and verify that all warnings disappear. Don’t think I’ve stuffed anything up in the process but I’m on PHP4 so anything’s possible.

Last edited by Bloke (2009-02-23 13:15:49)

azw · 2009-02-23 19:31:56

I’ll test it more a bit later, but after a quick test seems it seems to be working great! Thanks, Stef!

azw · 2009-02-24 05:11:32

Oh, boy, this is a weird one. I’m not sure what the problem is, but maybe you’ll have an idea.

I used the “Create new plugin” option and typed in simple code:

phpInfo.php;

When I save that file, which is placed in the plugin_cache_dir, I lose control of the site, on both the admin and public sides. Any page I go to is my new phpInfo.php page. I have to remove the .php extension (adding .txt works) to be able to access anything else. Disabling composer doesn’t affect this odd behavior, except that I can’t create another zombie file! It’s a cool affect, but quickly irritating.

Once I regain control of the site, I have to login again to get into the admin side.

I have edited an existing file in composer and not had the same problem occur.

What do you think causes this?

Last edited by azw (2009-02-24 05:38:07)

Bloke · 2009-02-24 09:12:04

azw wrote:

I used the “Create new plugin” option and typed in simple code: phpInfo.php;… Any page I go to is my new phpInfo.php page.

Uhhh, isn’t that because cached plugins are loaded on every page automatically? If you put the phpInfo() call inside a function () { ... } you’ll be fine I think :-)

Last edited by Bloke (2009-02-24 09:12:57)

azw · 2009-02-24 17:37:46

Heh, heh, you know when I went to bed last night I wondered about that. Thanks. I learned something. Again.

And here I was thinking you’d created a great zombie plugin. (That’s still something to consider!)

Last edited by azw (2009-02-24 17:38:44)

azw · 2009-03-02 08:20:23

Hey, Stef, this plugin has been very helpful. Thanks!

I’ve not had success with CSS I add to the CSS textarea. I don’t see changes in either the admin side or the public side. I need to change both the admin and public sides.

I can change the admin side css manually by editing to the /textpattern/textpattern.css file, but I’d rather do it via the plugin.

Am I missing something? (Well, besides that!)

Here’s some CSS I’ve tried:

table#azw_lm_list th,
table#azw_lm_list th a {
text-align: left;
margin: inherit, 0;
padding: inherit, 0;
}

*, a, td, p, div { color: green;}

Those work on the admin side (but not the public) if added manually to the /textpattern/textpattern.css file.

For the admin side is the only plugin option to embed the css directly into the admin side’s html?

UPDATE:

I see if I look at the plugin in a texteditor, there is a conditional wrapped around the CSS section:

}
# --- END PLUGIN CODE ---

if (0) {
?>
<!--
# --- BEGIN PLUGIN CSS ---
<style type="text/css">

If I change that 0 to a 1, the CSS I add in composer works on the public side. Is there a way to change that to TRUE in composer?

Of course, I’m still wondering how to handle css on the admin side.

Last edited by azw (2009-03-02 08:34:19)

Bloke · 2009-03-02 09:04:56

azw wrote:

I’ve not had success with CSS I add to the CSS textarea. I don’t see changes in either the admin side or the public side.

The CSS area in the composer’s Edit screen is only for the plugin help text. Sorry if that’s not clear in the documentation, I’ll change it to make it more obvious in the next revision.

If you want to put CSS in your plugin code you need to do it inline in your code. For the admin side you can attach a callback function to the head_end step which will inject the contents immediately before the closing </head> of the page.

On the public (or indeed admin) side you can use heredoc to insert inline style info for the few items you need to manage, e.g.

echo <<<EOCSS
<style type="text/css">
.rule {
   background-color: blue;
}
</style>
EOCSS;

Any significant quantity of rules and it may become easier to ship a stylesheet with the plugin or use some plugin installation routine to insert a BASE-64-encoded stylesheet directly in the txp_css table.

Does that help at all?

P.S. for plugin help text styling, I tend to find that wrapping your entire help text in a div (e.g. <div id="smd_help">h1. smd_mega plugin blah blaah</div> means it’s easier to target stuff for CSS. I stole that idea off net-carver and it works a treat.

azw · 2009-03-02 09:41:27

Yes, that’s very helpful.

Thanks again for good advice that’s easy to follow.

Now I can get rid of my green text!

azw · 2009-03-03 08:43:28

Wow, that’s hot! I’ll paste this here in case it’ll help someone else learn how to insert css into the admin side of a plugin.

I pasted this into my main callback right after declaring the globals:

function azw_lm()
{
    global $vars;
    global $event, $step;

   // call back to insert css into admin side: function to call, event, step
   register_callback('azw_lm_css', 'admin_side', 'head_end' );

And then I added this function elsewhere:

function azw_lm_css()
{

echo <<<EOCSS

<style type="text/css">

table#azw_lm_list th,
table#azw_lm_list th a {
text-align: left;
margin: inherit, 0;
padding: inherit, 0;
}

</style>
EOCSS;

}

It’s easy and works great. Thanks again, Stef!

azw · 2009-03-03 08:46:02

What is this?

If you read the plugin template in a text editor, you’ll see this conditional wrapped around the CSS section:

}

—- END PLUGIN CODE —-

if (0) { ?> <!—

—- BEGIN PLUGIN CSS —-
<style type=“text/css”>

I think if I change that 0 to a 1, the CSS I add in composer works on the public side.

Is that right? I didn’t see a way to change that to TRUE in composer.

Bloke · 2009-03-03 09:11:20

azw

Glad you got the CSS going on the admin side. Thanks for posting your code.

The if (0) is something that is in the standard TXP template. I have no idea why it’s there, it just is and has been since zem (I think) set the template up on day 1. It works and it was dutifully copied into the Composer so it generates templates in exactly the same standard manner, such that they may be interchanged with other developers and/or used to compile a plugin from the command line.

The only thing I (well, net-carver) did differently was allow the code and help segments to be swapped over in the template. It makes no difference to command line compilation, it’s merely for aesthetics.

I don’t know if changing the 0 to a 1 would have any knock-on effects anywhere else, or indeed if it would work when the plugin was compiled. It would be interesting to see what the compiled plugin looks like when transferred to another TXP and installed via Admin->Plugins. I doubt the style block would appear because it’s supposed to be stored in the help field along with the documentation, neither of which would be rendered public side. But I could be wrong. If you’d like to try it one day, then feel free to report your findings.

I suspect this is just a “feature” of using the composer in the plugin cache dir.

Last edited by Bloke (2009-03-03 09:13:31)

azw · 2009-03-03 22:22:08

I’ve tested the plugin template to see what that conditional wrapped around the CSS section does. In these tests, I was unable to get any CSS changes to appear in either the admin or the client (public) side. I’m not sure what accounts for the fact that I was seeing green text earlier. (Nah, it wasn’t just the late night.)

Actually, I did notice one difference. If my plugin is in the plugin_cache_dir and I change the “0” to “1”, the font size increases throughout the site (except on the Plugins tab, as you would expect). That’s the kind of malfunction I’ve seen at other times if characters are written before the <?php tag at the top of a page.

And, yes, that’s exactly what was happening. The “1” allows the CSS and help parts of the plugin to be written above the code of the page.

I didn’t look at how it affects the compiled plugin, but I suspect it doesn’t, because the “1” doesn’t have this effect if I save the plugin and install it on another Textpattern site.

}

   1. —- END PLUGIN CODE —-

if (0) {
?>
<!—

   1. —- BEGIN PLUGIN CSS —-


<style type=“text/css”>

azw · 2009-03-06 08:54:03

Hi, Stef,

I don’t think this is a bug, but it’s behavior worth noting in the event that others are baffled by this.

If I have the glz_custom_fields plugin by Gerhard Lazu activated, it sometimes adds its JavaScript and CSS to another plugin if I use the link at the bottom of the page to save the plugin as a php file: Save as xxx_xxx_0.1.php

I discovered this when I edited my plugin in an external editor and then saved it to the plugin_cache_dir. The PHP engine didn’t like the JavaScript and threw errors.

The solution is simple: make glz_custom_fields not active.

I wonder if this occurs because of the way Gerhard injects JavaScript and CSS into Textpattern with this function?

// adds the css & js we need
function glz_custom_fields_css_js($buffer) { 

.... then he uses two HEREDOCs to add his JavaScript and CSS to variables ....

  $find = '</head>';
  $replace = $js.n.t.$css.n.t.$find;

  return str_replace($find, $replace, $buffer);
}

Last edited by azw (2009-03-06 08:54:36)

Textpattern CMS

Textpattern CMS support forum

#91 2009-02-22 03:18:50

Re: ied_plugin_composer - new plugins never came that easy

#92 2009-02-22 13:09:59

Re: ied_plugin_composer - new plugins never came that easy

#93 2009-02-23 13:14:55

Re: ied_plugin_composer - new plugins never came that easy

#94 2009-02-23 19:31:56

Re: ied_plugin_composer - new plugins never came that easy

#95 2009-02-24 05:11:32

Re: ied_plugin_composer - new plugins never came that easy

#96 2009-02-24 09:12:04

Re: ied_plugin_composer - new plugins never came that easy

#97 2009-02-24 17:37:46

Re: ied_plugin_composer - new plugins never came that easy

#98 2009-03-02 08:20:23

Re: ied_plugin_composer - new plugins never came that easy

#99 2009-03-02 09:04:56

Re: ied_plugin_composer - new plugins never came that easy

#100 2009-03-02 09:41:27

Re: ied_plugin_composer - new plugins never came that easy

#101 2009-03-03 08:43:28

Re: ied_plugin_composer - new plugins never came that easy

#102 2009-03-03 08:46:02

Re: ied_plugin_composer - new plugins never came that easy

#103 2009-03-03 09:11:20

Re: ied_plugin_composer - new plugins never came that easy

#104 2009-03-03 22:22:08

Re: ied_plugin_composer - new plugins never came that easy

#105 2009-03-06 08:54:03

Re: ied_plugin_composer - new plugins never came that easy

Board footer