sadara

hi paul –

the full error message i see is:

Plugin could not be activated because it triggered a fatal error.

<strong>Parse error: syntax error, unexpected '[', expecting ',' or ';' in D:\INETPUB\VHOSTS\<domainname.tld>\<subdomainname>\wp-content\plugins\dukagate\dukagate\dukagate-settings.php on line 41</strong>

amending the line to:

echo array_keys($this->variation_types, $key);

enables me to activate without error. i suppose that since the function has been disabled, changing it like this shouldn’t cause any problems.

for your info:

• i’m using a zip of dukagate v3.4.9 downloaded 27/10/13
• wordpress 3.7
• installing using the .zip upload & install functionality in wp admin area.
• php 5.2.17 running on windows

thanks for the response

3.4.9

You may also need to check the name of the field <prefix>user_roles in the table <prefix>options. It may have been changed from <oldprefix>user_roles to <newprefix>user_roles.

Likewise check the values in the field meta_key in the table <prefix>usermeta. <oldprefix>user_level may have been changed to <newprefix>user_level; <oldprefix>utosave_draft_ids may have been changed to <newprefix>utosave_draft_ids.

the presence of the file doesn’t bother me. and now that samboll has told me that the information in the readme applies to 2.6.3 as well as 2.6.1, i have had no problem performing the upgrade.

readme files rarely do have an impact on how packages function, but they often do to how packages are installed. if it doesn’t matter what’s in it, why have one?

hi MichaelH –

there’s really no need for sarcasm. i could easily change the file, but … what would i put in it?

readme files are there to be read and to contain information thought to be relevant to people installing a package.

thanks samboll.

not sure to whom i should be addressing this remark, but perhaps someone could take the time to put this right? why be so english?! someone definitely SHOULD put this right!

I’ve just downloaded the package again and the readme still relates to 2.6.1.

There’s no way I’m going to install this version without first reading what I’m likely to be getting myself into.

i’m using 1.5.1.2.

the language file nl_NL.mo was not being used; i was getting en_US instead of nl_NL. WPLANG was set up ok in wp-config.php.

in wp-l10n.php, in the function get_locale(), the first instruction is:

if (isset($locale)) return $locale;

the code to check WPLANG and then to set the value of $locale appears *after* this instruction.

on two of the 3 plesk systems i use (including the one where i was having this problem with nl_NL), the value of $locale is set by the system, in one case to ‘en’ and in the other to ‘en-US’. on the third system, $locale is not set. therefore, on the two machines where $locale is already defined by the system, control was returning from the function before the value of WPLANG was being checked.

as the values for $locale used by wordpress are in the form xx_xx, i’ve changed the instruction quoted above to:

if (isset($locale) && stristr($locale,'_') > 0) return $locale;

i’m not happy with this hack. maybe the name of the variable could be changed to ‘wp-locale’?

dangcookie wrote:

By the way, don’t forget to apply the solutions provided in this thread to both $post_content and $post_title. ??

… and $post_excerpt!

magic_quotes_gpc affects the handling of get, post & cookie variables. on my machine the value of magic_quotes_gpc is ‘On’.

it would not be effective in the handling of email-delivered posts (no get, post or cookie variables involved), hence the above hack. but when posts are inserted / updated using forms, all is ok.

at least, that seems the most likely explanation for the behaviour i’ve seen. i haven’t looked too deeply into it!

i’m having this problem – but only when my post is submitted by email and loaded using wp-mail.php. the single quotes, it seems, are not being escaped in the sql statement used to insert the post in the database.

mine is a new installation (90 minutes old) of 1.5.1.3.

the problem is solved by adding the function addslashes() to the sql statement at around line 49 of functions-post.php to read:

$sql = “INSERT INTO $wpdb->posts
(post_author, post_date, post_date_gmt, post_modified, post_modified_gmt, post_content, post_title, post_excerpt, post_category, post_status, post_name, comment_status, ping_status, post_parent)
VALUES (‘$post_author’, ‘$post_date’, ‘$post_date_gmt’, ‘$post_date’, ‘$post_date_gmt’, ‘”.addslashes($post_content).”‘, ‘$post_title’, ‘$post_excerpt’, ‘$post_cat’, ‘$post_status’, ‘$post_name’, ‘$comment_status’, ‘$ping_status’, ‘$post_parent’)”;

quite possibly the same problem exists in the posting of comments. but i haven’t tested that.