All Low add-ons are now owned by EEHarbor. Read the blog post.

Support archive

Variables saved as file issue

Siebird 31 Jan 2013 19:55 problem, active

Hi,

I'm having random issues when editing a early parsed variable saved as a file. Seems erratic at this point and I can't figure out why. For instance, I have a lv_inc_footer variable that has 94 lines. The variable was working fine until I made a edit over FTP. The variable parses fine, but leaves the closing } of the entries tag call:

{exp:channel:entries 
channel="news|events"
disable="categories|category_fields|member_data|pagination|trackbacks"
dynamic="no"
limit="4"
require_entry="yes"
}
<li><a href="{page_url}">{title}</a> <span class="icon icon-mini icon-{channel_short_name}">{channel}</span> {if channel_short_name == "news"}{entry_date format="%n/%j/%Y"}{/if}{if channel_short_name == "events"}{event_date:start_date format="%n/%j/%Y"}-{event_date:end_date format="%n/%j/%Y"}{/if}</li>
{/exp:channel:entries}


Renders:

<ul class="articles"> 
}
<li><a href="news-events/news/as-rss-are-only-for-high-rise-warehouses">AS/RS’s are Only for High Rise Warehouses</a> <span class="icon icon-mini icon-news">News</span> 1/11/2013</li>
}
<li><a href="news-events/event/promat2013">ProMat2013</a> <span class="icon icon-mini icon-events">Event</span> 1/21/2013-1/24/2013</li>
}
<li><a href="news-events/news/westfalia-launches-new-website">Westfalia Launches New Website</a> <span class="icon icon-mini icon-news">News</span> 1/8/2013</li>
}
<li><a href="news-events/news/westfalia20years">2012 - not just the end to another year for Westfalia</a> <span class="icon icon-mini icon-news">News</span> 1/8/2013</li>
</ul>


Now, if I copy/paste the code and save through the CP, the variable works fine. Does this have to do with the collation? It's set to latin1_swedish_ci?

Replies

  1. Low 1 Feb 2013 08:35

    Seems odd indeed. It's recommended that your DB collation is set to utf8_general_ci, not latin1. Also, what happens if you don't put that closing } in a new line, but directly after require_entry="yes"?

  2. Siebird 1 Feb 2013 21:41

    Where/how does the DB collation get set? Not even sure how it picked up the latin1?

    Re: closing }, I tried several variations of the tag and even retyped it. I'll try changing the collation to see if that fixes the issue (can't access the server at the moment)

  3. Low 2 Feb 2013 08:12

    When you create a new DB and don't set the collation then, it will default to latin1, and its last option: latin1_swedish_ci.

    Check the mysql docs: http://dev.mysql.com/doc/refman/5.0/e...
    And how to change it per table:

    alter table 'my_table' convert to character set utf8 collate utf8_general_ci;

  4. Stephen 4 Feb 2013 17:00

    Just chiming in on this latin1_swedish_ci issue.

    I've got a test install (EE 2.5.5 and Low Variables 2.3.2) and I recently noticed that every EE and EE add-on table in my install has a language of utf8_general_ci, except for the two Low Variables tables, which have a language of latin1_swedish_ci.

    I just assumed this was a Low Variables thing. I've just uninstalled then installed Low Variables again to double-check and noticed that the language for its tables is still latin1_swedish_ci.

    Maybe this is a bug with the installation routine if it's not happening with any other add-ons? I'm just using a default MAMP install.

  5. Stephen 5 Feb 2013 04:13

    Also for info, I was just upgrading add-ons on a live site and noticed that both Low Search and Low Reorder also have their tables in latin1_swedish_ci too.

  6. Low 5 Feb 2013 08:30

    My add-ons don't explicitly set the character set and collation when a table is created. When not explicitly set, it uses the default for the entire database, which *should* be utf8/utf8_general_ci.

    If the EE database was created without a default charset/collation, it will fall back to latin1/latin1_swedish_ci, so any Low add-ons will do the same.

    So, not necessarily a bug, but I can see how it would help to explicitly set the charset/collation to utf8, even though the DB itself is not.

  7. Stephen 5 Feb 2013 15:19

    Hi Low - thanks for this.

  8. Siebird 6 Feb 2013 00:48

    I can't figure this out. I thought maybe the collation was the issue. Set the collation to utf8_general_ci and the issue still persist. This time it adds the closing } to all tags within that template. If I copy/paste the contents into the textarea in the CP, all works as normal–saving from file is the culprit. Any other ideas?

    The client insisted hosting the site locally on their servers, so they installed WAMP on IIS, not sure if that has anything to do with it or if you had experience with this in the past. It might be a file permission issue.

    More of a hassel at this point, but I will deal with it.

  9. Low 7 Feb 2013 10:15

    So, is the extra } added to the variable itself after you update the text file? Or is it only displayed in the template?