Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Listing entries are not correctly parsed

Status	Resolved
Add-on / Version	Publisher
Severity	Critical
EE Version	24

Filip Vanderstappen

Jan 20, 2013

I’m using the following code for a blog listing ( /en/blog );

{exp:channel:entries channel="blog" dynamic="no"}
        <article>
            <h1><a href="{page_uri}">{title} ({page_uri})</a></h1>
<p>            {blog_intro}<br />
        </p>
</article>
<p>        {paginate}<br />
            </p><p>Page {current_page} of {total_pages} pages {pagination_links}</p>
<p>        {/paginate}<br />
    {/exp:channel:entries}

This results in a listing being parsed with the wrong {page_uri} (no language prefix) as you can see on this screenshot: http://cl.ly/image/0w350D1D3p1J

This screenshot is taken in ‘Production’ mode; as you can see the {blog_intro} (which is a Wygwam field) is only being parsed once and then used for all the following entries. However under ‘Development’ mode this is parsed correctly.

BoldMinded (Brian)

page_uri won’t be able to have the prefix appended to it because it takes the value directly from the site_pages array for each entry. The prefix is only prepended to the site_url variable in the site_pages array. So page_url will work instead of page_uri, b/c page_url is a concatenation of site_url + page_uri, thus it gets the prefix. Is there a reason you can’t use page_url instead of page_uri? page_url is actually more reliable because it has the full url, so if you have the site setup in a sub-directory links will continue to work. page_uri would be linking to root b/c it starts with a forward slash.

BoldMinded (Brian)

As for the Wygwam field, open the Publisher_lib.php file, and around line 76 you’ll see:

$is_replace_variant = substr($method, 0, 7) == 'replace' ? TRUE : FALSE;

change it to:

$is_replace_variant = (substr($method, 0, 7) == 'replace' OR $method == 'pre_process') ? TRUE : FALSE;

That should fix up Wygwam (and any other field that uses pre_process)

Filip Vanderstappen

Thanks for the quick reply. You are completely right about the {page_uri} vs {page_url}, it doesn’t matter because I’m bootstrapping the config on all environments.

Your code change fixes the the bug on ‘Production’ and it still works on ‘Development’. Thanks for the follow up!

BoldMinded (Brian)

Excellent! I’ll add something to the docs about page_uri vs page_url