Paul, what happens when < or > is part of the text?  Will EE have doubly escaped these into < and >?

~joe

Since they are already entities, they should be preserved as entities.

As for the search excerpt, I believe there is already plans to make the length of the excerpt settable or have an variable for showing the full contents of the excerpt field.  And since the next version will also allow nested plugins, you can use either Filter_HTML or the combination of word_limit and html_strip.

Paul,

I think I’ve found a plugin/hack combination that will allow us to nest plugins now.  How long is our wait for the EE that supports nesting?  Should I bother with a temporary fix?

~joe

The addition for allowing nested plugins is relatively small, and if you can do it now then do it since the next version of EE is probably not happening this week.

Hmm.  My fix isn’t as small as I’d like it to be, and it requires that people do special things with their templates.  If the wait for the official fix is still months away, then I’ll probably go ahead with it.  If the official fix is weeks away, then I’ll hold off.

~joe

I could email you my fix, if you so desire.  We’re only beginning to test it out, but so far it seems fine and it saves us from rewriting any of the template engine’s current code.

I would like to see it.  But more, a number of people using filter_html keep butting their heads up against the nesting problem.  I was hoping to make it possible to use filter_html in more contexts.

I am curious, though.  How do you scope plugin variables to the appropriate plugin?  Suppose you want to use an outer tag’s variables inside an inner tag?  I was planning to require fully-scoped variable names akin to {exp:weblog->total_comments}.

My fix would have been a bit heavy because I didn’t want to reverse engineer the EE template code.  I think there’s a way to do it without knowing the internals—but then my plugin would have to provide complete control over scope resolution.

Normally, EE parses tags outwardly in, so the tag that is on the outmost region is rendered first and thus has priority as does its variables.  There is no namespacing, only unique names and the mentioned priority. 

We recognize a tag as calling a plugin quite simply by seeing if it is located in the plugin directory.  If a module and a plugin have the same name, I believe that the module will be recognized first and thus has priority.  Once again no kind of name spacing is used here (we option not to do exp:module:module_name and exp:plugin:plugin_name).  What the addition to the template engine that allows nested plugin does is for a limited amount of content it reverses the outwardly in approach to parsing.  If a plugin is found and it has an EE tag enclosed (starts with {exp:), then it stops, takes the contents of that plugin (what is ever between the opening and closing tags), and parses what is inside first before parsing that first plugin.

As for fully scoped variable names, there is absolutely nothing to stop you from using them in your own modules and plugins, but the current EE modules do not use them.  Perhaps in a future version of EE we will allow the “option” of using them, so if an admin sees a situation where confusion might develop he can use them.  Otherwise, he could use the simpler ones.

As the template engine becomes more and more complicated (as if it is not enough), the power of it goes up but its speed goes down.  There is a tough balance to reach in this area, and we are definitely not trying to make EE template parsing into something as complicated as a programming language parser (not that there were not ideas about it).  We wish to steer quite clear of there, you can understand.

I can’t say I understand the ramifications of this change.  Seems like things might be a bit unpredictable to outside-in parse some times and inside-out parse at other times.

What if I have a plugin that repeats the contents between its tags, once for each of some kind of item.  And suppose the contents of those tags has a call to another plugin.  The call to that other plugin should be made once per iteration of the outer plugin.

In the reverse case, a nested iterated plugin should fully iterate before applying an outer plugin, such as my filter_html.

How does your fix handle these situations?

~joe

Oh, forgot to mention that I sent Rick some ideas for improving parse speed.  You can actually bring the runtime cost of parsing down to near nothing.

The complexity of the parsing code will continue to increase, but I think the regex approach forces you to keep adding code in equal weight to your enhancements, risking match interference with each new syntactic component.  I think it’s better to fix the tokens, emit these tokens via a tokenizer, and have a single, extensible parser that centralizes token handling.  In this way the code layers in abstractions, so logical additions stay at the logical level and syntactic additions stay at the syntactic level.

Real quick, since there is many other things to do today:  With the current template parser, the only other option was to make it far more complicated and while this may seem to be unpredictable it really is not.  Since the plugin is meant to modify the content inside of it, if the content inside of it contains unparsed EE tags it makes sense to parse those tags first so we can get real content.

Once per iteration?  Why not call the inner plugin once on the content and then do the loop.  If you are thinking that the outer plugin during every loop causes a change in how that inner plugin is done during every loop (via a variable in a parameter or other way), then yes it will not work.  This sounds like an incredibly complex and specific example that will not occur for most of our users, so if that is how you wish it to work it seems a specific plugin might be called for.

Yes, Rick passed along your ideas and while the terminology used was a bit wacky, I believe I understood where your ideas were going.  The Template parser’s original concept(s) and code were figured out early along in EE’s development, and we know that we are going to have to rewrite the parser eventually.

Here’s the results of a search on my site:
—-
T-Mobile to Axe the MPx?
http://www.the3gportal.com/images/uploads/mpx.jpgDouble trouble from Motorola-Land today. According to rumor, T-Mobile has DROPPED the MPx100 Smartphone from its scheduled rollout, and is considering doing the same with the MPx. <a target=“_new” class=“effect1” href=“http://www.the3gportal.com/cgi-bin/framer/framer.cgi?http://www.pocketpcthoughts.com/index.php?action=expand,29616&sid=8a5e8049c4132531230166b479339368”>Full Story & Source: pocketpcthoughts.com</a>
——

Today I finally upgraded from PB2 to the latest Version 1.0 - and can’t recall if the HTML used to appear in the search results? But regardless, now it does and its ugly - so when I found this post “HTML Stripped from Search Results” and the existence of a plug-in to achieve the goal I was so pleased.

I have now uploaded the plug-in - HTML Strip - and did a search and got the same combination of text and html in my search results (the html is there because I pull in images into the posting).

So my question is could someone please advise me how to get the plug-in to strip out the html out of the search results (if this is what it can do)?

Perhaps I have to add some tags to my templates - if so, could I have a layman’s explanation on how to do this Thanks

Steve

Sorry posted request for help in wrong section ! Do not answer here but see same post in Technical Problems section

Try adding the parameter convert=“y” to the plugin tag.