Module Parsing Order

Leevi,

I’ve run into the same sort of thing a few times before.

Parse order for modules happens in order of occurrence within a template. So an outer module always gets parsed before an inner one.

This is of course not always what one wants. In your case you could try getting around it by using the module tags around the entries tag and creating a variable that is replaced instead of the module tag within.

Here is an example from Derek Jones using the query module around the entries module where the query module obviously needs to parse first (and does) in order for the desired result.

{exp:query sql="SELECT url_title FROM exp_weblog_titles WHERE entry_id = '1'"}
    {exp:weblog:entries url_title="{url_title}"}
        {title}
    {/exp:weblog:entries}
{/exp:query}

In the case of modules there is no parse=”inward” parameter you can set.

Jamie

Leevi, this sounds like you might better be served with an extension of the weblog module.

Thanks guys for the feedback.

@Jamie: I don’t think that will work for my module.

@ Derek: An extension to the weblog module?? Where is that documented. I guess I missed it.

Anyway I spose I can open up a little more on my module.

Its actually a new polling module. The idea is that poll information is stored as a custom field in a polls weblog.

Basically the way it works is this:

1. Install the module

   • The module has allows you to set the modules configuration, list polls, display results
   • Part of the configuration is the polls template & the results template
   • The polls template renders a new poll form
   • The results template renders the results
   • I am storing these in the backend so I can submit the polls via ajax and display the results (more on that later)

2. Install the 2 extensions

   • LG Polls Question: A custom field for a poll question (just a text field with a special custom field type)
   • LG Polls Details: A custom filed that stores the possible answers and per poll configuuration

3. Create a new Weblog called “polls”

4. Configure the module and select the “polls” weblog as the weblog that will store the polls.

5. Create a new poll

Once a poll has been created it can be rendered using the {exp:lg_polls:poll} tag which takes an entry id param. The module does its work and spits out a poll, results or error based on the configuration of the poll and the user.

The idea was that the poll templates that where stored in the backend could contain any custom fields from the polls weblog and these would be rendered like normal. This doesn’t seem possible so what I’m thinking is that I will pass a new question param to the module, or rework the poll template just to render the radio inputs.

So here are a couple of screens of what I got so far….

Well it seems as if your module’s only purpose is to modify information that will be output by / given to the weblog entries tag, which makes much more sense to me to handle in one of these two places, depending on what your needs are: weblog_entries_tagdata weblog_entries_tagdata_end

Also heres the template that the user would need to implement

{exp:weblog:entries weblog="polls"}

{exp:lg_polls:poll entry_id="{entry_id}"}

    <!-- if the user is a member of a non restricted group -->
    <!-- if allow_duplicates is set to yes or the user has not voted -->
    {if can_vote}
        
        <!-- Render Poll form Template-->
       {poll_template}

    <!-- The user cannot vote for any number of reasons -->
    {if:else}

        <!-- If the user has already voted -->
        {if has_voted}
            You have already voted in this poll.
        {/if}

        <!-- If the user is not a member of the required group -->
        {if restricted}
            You are restricted from voting in this poll.
        {/if}

        <!-- If the poll has expired -->
        {if expired}
            This poll closed on {end_date}
        {/if}

        <!-- If the poll is not yet active -->
        {if yet_to_begin}
            This poll is yet to begin. Voting opens on {start_date}
        {/if}

    {/if}

    <!-- if the setting results_mode = show_before -->
    <!-- if the user has voted previously and allow_duplicates is off -->
    {if show_results}

        <!-- Render results Template-->
       {results_template}

    {/if}

{/exp:lg_polls:poll}

{/exp:weblog:entries}

If the user wanted to create a poll on its own he/she could also just use the module and set the entry id another way. I have also written another custom field that adds a drop down of all the current polls making it an easy process to attach a poll to a post.

In the example above you can see that I have {poll_template} & {results_template} these get replace in the module and output the configuration settings.

Well it seems as if your module’s only purpose is to modify information that will be output by / given to the weblog entries tag, which makes much more sense to me to handle in one of these two places, depending on what your needs are: weblog_entries_tagdata weblog_entries_tagdata_end

I’ll keep those hooks in mind. They look nice and powerful.

I think this module will be used for standalone polls as well… like in the sidebar and probably don’t need to use the weblog:entries tag.

I will think about this some more tho.

Update: If its not using the weblog entries tag how amy I going to get the custom fields!!!!! arrrghhhh my head hurts now

Well it seems as if your module’s only purpose is to modify information that will be output by / given to the weblog entries tag, which makes much more sense to me to handle in one of these two places, depending on what your needs are: weblog_entries_tagdata weblog_entries_tagdata_end

Do these hooks allow you to check relationships as well?

You have access to the tagdata, the row of data for the entry, and the weblog $this object. So you can really do whatever you want, though it is not going to have relationship information compiled at that time; that does not occur until later in the weblog module. You’ll have markers in place of the data at this point. My recommendation would be to build a simple extension on these hooks, and do a print_r() or var_dump() on the arguments passed to your method. Then you’ll have a good idea of exactly what you can or cannot do.

You have access to the tagdata, the row of data for the entry, and the weblog $this object. So you can really do whatever you want, though it is not going to have relationship information compiled at that time; that does not occur until later in the weblog module. You’ll have markers in place of the data at this point. My recommendation would be to build a simple extension on these hooks, and do a print_r() or var_dump() on the arguments passed to your method. Then you’ll have a good idea of exactly what you can or cannot do.

already working on it!