if ((mt_rand() % 100) < $SESS->gc_probability)
{
$old = time() - $expiration;
$DB->query("DELETE FROM exp_captcha WHERE date < ".$old);
list($usec, $sec) = explode(" ", microtime());
$now = ((float)$usec + (float)$sec);
Short term- advised to copy
list($usec, $sec) = explode(" ", microtime());
$now = ((float)$usec + (float)$sec);
Above the conditional to avoid error.
]]>When I try to read the cookie from inside ee using $_COOKIE, the cookie is changed.
The call $IN->fetch_input_data() in core.system.php modifies the cookie data in such a way that our external application no longer recognizes it.
Being that everything we allow a user to do is determined by the contents of the cookie, this issue has us dead in the water. I could comment out your code that ‘cleans’ the cookie, but I would like to know if this would be addressed in a future release. I don’t want to have to comment out code in your app whenever you put out a release.
Sample code to reproduce the problem has been posted in the support forum at http://expressionengine.com/forums/viewthread/82310/
]]>Changes do not stick, and you get an error that your original (local) server paths are not valid.
There is a workaround ‘hack’ to change the settings using Find and Replace utility.
See these two threads for more background:
http://expressionengine.com/forums/viewthread/81916/
http://expressionengine.com/forums/viewthread/60041/
Long thread- boils down to- if you already have custom cat fields created and you duplicate a weblog when creating an MSM site- the exp_category_fields table gets the new rows added ok- but the exp_category_field_data table doesn’t get the new fields to match them added. So- when you go to edit categories on your new msm site, you get a mysql error:
Error Number: 1054
Description: Unknown column 'field_id_3' in 'field list'
Query: UPDATE `exp_category_field_data` SET `field_id_3` = '', `field_ft_3` = 'none' WHERE cat_id = '45'
Because- it’s missing those fields.
]]>
{auto_thread_path}
This variable is replaced by a path built with the URL set in the "Forum URL" general preference setting for the board that the topic belongs to. For example, this:
<a href="{auto_thread_path}">{title}</a>
Would be rendered like this:
<a href="http://www.example.com/index.php/forums/viewthread/11245/">My forum topic</a>
But he’s right- if I use
<a href="{auto_thread_path}"><b>{last_author}</b> posted on the topic <br />
The generated paths look like http://media-cow.com/forums/39/ - need the viewthread bit in there to work properly.
]]>Then that same view count (invariable not-synched actual view count) is parses “AS IS” in the weblogs module’s parsing methods.
There be a snippet in there to correct view counts?
I’ll be using a custom extension until this is addressed.
]]>Even though a particular forum and all posts in it were correctly deleted, and no longer acessible, the stats were off. Users were still credited with postings that no longer existed, as well as the “Most Recent Forum Post” in their profiles.
Re-synchronizing the forums did not help, as I could confirm on my sandbox.
]]>If a db prefix other than “exp” is used, but starts with “exp_”, EE will remove the leading “exp_” and replace it with the custom prefix when saving, still leaving the second part in place.
I can confirm this in build 20080421. Having tried “exp_ig”, EE rewrote that to “exp_ig_ig”, “exp_ig_ig_ig”, and so on.
]]>
If you end a field with a backslash:
something\
Then use that field in a conditional:
It’s throwing a t string error. Replicated on my install.
Changing the Server Path to reflect the desired avatar upload path is not reflected when attempting to save the setting:
For example if I set the server path to: /html/uploads/avatars/
When I try to save the path I get an error message stating that the path is not valid, however EE is trying to use a different path to the one specified, i.e. EE tries to use: /html/uploads/avatars/uploads/
So it is applying the directory path “uploads” even though this is not specified.
]]>I am currently using a conditional as a temporary fix to prevent the display of closed entries, but I believe the {related_entries} tag pair should respect the status of entries for the sake of consistency at the very least.
]]>