ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Can a plugin be used through an entry?

July 09, 2007 3:32am

Subscribe [4]
  • #1 / Jul 09, 2007 3:32am

    Davmit

    11 posts

    Hi Friends,

    I have created a Plugin which i want to use through an entry
    Can we do that?

    or is there another solution for it

    Thanks,
    Davmit

  • #2 / Jul 09, 2007 10:40am

    PXLated

    1800 posts

    I think you’ll need to explain a little further.

  • #3 / Jul 09, 2007 11:56am

    Derek Jones

    7561 posts

    Davmit, if you mean that you want to use a plugin tag inside the contents of an entry, then you can use the Allow EE Code plugin, but I highly recommend against that, as it will allow ANY tag to be used in an entry.  Further, tags within entry content isn’t giving you a good separation between your content and tags.  What I would do instead, is use a special syntax for text that needs to be processed by the plugin, use the plugin tag in the template, and let it process it that way.  This would be akin to how pMcode works.

    For instance, if you had a plugin named Capitalize that changes the first letter of each word to capital letters, instead of this in your custom field:

    {exp:capitalize}this is the text{/exp:capitalize}

    I would use in the entry:

    [capitalize]this is the text[/capitalize]

    and in the template:

    {exp:capitalize}{custom_field}{/exp:capitalize}

    And the Capitalize plugin would parse the [capitalize][/capitalize] tag pair out of the custom field content and process the text as needed.

  • #4 / Jul 10, 2007 4:24am

    Davmit

    11 posts

    Thanks for the help Derek
    it helped a lot!

  • #5 / Jul 17, 2007 3:48pm

    Mark Huot

    587 posts

    Is there any way a plugin could set itself, through a setting of some sort, to be parsed either before or after template vars have been parsed?  Sort of like how you can choose to parse PHP before or after the template parser?  Then certain plugins could be set to parse before the variables have been replaced, and thereby allow tags like {title} to be picked up by the plugin.

  • #6 / Jul 17, 2007 3:55pm

    Derek Jones

    7561 posts

    Mark, just put your plugin tag around the weblog entries (or other module’s) tag, tags are parsed in order encountered.

  • #7 / Jul 17, 2007 4:00pm

    Mark Huot

    587 posts

    Let me explain a little:

    {exp:weblog:entries}
    <html>
    <head>
    <title>{title}</title>
    </head>
    <body>
    <h1>{title}</h1>
    {body}
    {exp:plugin_here}<a href="http://{plugin_variable}" title="{title}">{title}</a>{/exp:plugin_here}
    </body>
    </html>

    In the above, the plugin_here plugin loops though it’s contents and creates a list of somewhat related entries.  Because I’m using the contents of the plugin tag to display in a list, I can’t wrap the entire tag in the plugin or I’d get a list of many html tags.  Right now I’m using the bracket ([title]) approach, and it’s working, it just feels wrong for some reason.

  • #8 / Jul 17, 2007 4:06pm

    Derek Jones

    7561 posts

    I’m confused Mark.  You want your plugin to output {title} and not the parent weblog entries tag?  If so, why not just name it something else that doesn’t conflict with the parent tag variables?

  • #9 / Jul 17, 2007 4:32pm

    Mark Huot

    587 posts

    I certainly can, but since it’s outputting entries, with titles, dates, and url_titles I figured the easiest way to remember the tags would be to use the actual field names.  I could always make them {pi_title} I was just hoping there was a way to avoid the additional tag names.  Make sense?  It’s been a long few days so let me know if that’s still confusing.

  • #10 / Jul 17, 2007 5:32pm

    Derek Jones

    7561 posts

    Yes, it does make sense, but what you see as a workaround, I see as working with, that is to say, working exactly as plugins are designed and in harmony with the template parser.  But you could easily get the parsing behavior you are looking for by using an extension of the weblog entries tag instead of a plugin tag, though, and do something akin to:

    {extension_here}<a href="http://{extension_variable}" title="{title}">{title}</a>{/extension_here}

    Make sense?

  • #11 / Jul 17, 2007 5:40pm

    Mark Huot

    587 posts

    I see, and then I could jump in at the weblog_entries_tagdata hook and parse out the vars before the weblog module got a hold of it.  That makes perfect sense, except for one thing.  That would only work if the tag is inside an entries tag.  Ideally the plugin would work wether it’s inside of or outside an entries tag, and if it’s outside the tag there is no way for the extension to grab a hold of the tagdata surrounding the plugin.

    ::sheepishly:: sorry about all this, i’m not trying to be difficult ::/sheepishly::

  • #12 / Jul 17, 2007 5:54pm

    Derek Jones

    7561 posts

    Either wrapping the tag, prefixing the variables, or a substitute for ‘{' / '}’ are your best bets.  The last two are really easy enough for any user editing templates to grasp, if properly documented with your add-on.  The nature of the template parser is that tags are evaluated as they are encountered, so the weblog entries tag is going to be seen, and its variables parsed, before the template parser would ever even know that {exp:plugin_here} existed.  So having that plugin somehow be an exception to this natural parse order would be not be possible.  What you’re looking to do is very much like nesting a weblog entries tag inside another, which would also have variable conflicts.

    One outside the box option, is that you have an extension and a plugin, and use {exp:extension_name}...{/exp:extension_name}.  In the weblog entries tag, your extension will parse that out.  Outside of the weblog entries tag, the plugin would be called.

    Though, I think the water being treaded here looks rather murky.  Perhaps a new thread in the plugins forum describing the purpose and needs of the add-on would be best, and a reasonable, safe solution can be found.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases