ied_plugin_composer - new plugins never came that easy

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)

Bloke · 2009-03-06 09:13:13

azw wrote:

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:

Oooh, yeah, that’s nasty. I guess if your plugin uses </head> anywhere in its code then glz_custom_fields will inject its stuff. Perhaps Gerhard is indiscriminate about on which pages the JS/CSS is applied?

The solution is simple: make glz_custom_fields not active

Cool. A few other possible solutions (untested):

make the ied_plugin_composer a higher priority than glz_custom_fields
install the plugin composer before installing glz_custom_fields so it is run before Gerhard’s plugin
use the plugin cache dir for your own plugin (and/or ied_plugin_composer) so it is always loaded before any database-installed plugins

I’m not sure if any of those will work but my (loose) understanding is that the cache dir is read first and then all other plugins are loaded in the order they were installed, unless overridden with the load order. It may be alphabetical now though (in which case glz_custom_fields still comes before ied_plugin_composer!) I’m not sure.

Thanks for the report.

Last edited by Bloke (2009-03-06 09:17:33)

azw · 2009-03-06 09:47:54

Yep, you guessed right. His code is added right before </head>. Good point.

I think you’re also right that Gerhard adds his JS and CSS to every page. That may not be necessary, so I’ll drop let him know about the conflict.

Unfortunately, 1 and 2 didn’t work.

I doubt that 3 will work, either, since the damage is done when the php file is saved in Composer, before it even gets into the plugin_cache_dir. On my system, its first saved in a temp folder.

Thanks for the quick response!

redbot · 2009-03-06 11:17:12

azw wrote:

I think you’re also right that Gerhard adds his JS and CSS to every page.

Yes, it does :(

Textpattern CMS

Textpattern CMS support forum

#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

#106 2009-03-06 09:13:13

Re: ied_plugin_composer - new plugins never came that easy

#107 2009-03-06 09:47:54

Re: ied_plugin_composer - new plugins never came that easy

#108 2009-03-06 11:17:12

Re: ied_plugin_composer - new plugins never came that easy

Board footer