Date format *\* backslash to escape characters

[pedro-mendonca]

In the description of this setting it says this:

Depending on your Date / Time Conversion Mode, you can either enter a strftime (use %q for day suffix (st,nd,rd,th)) or date format. This field is optional. (Example: %A %B %e%q, %Y)

At least in the function date one can use escaping characters as at by preceding it with backslash \a\t as described here:
https://codex.wordpress.org/Formatting_Date_and_Time

The problem is that If I add this \(backslash) in the Date format field, after saving it adds an aditional backslash: \\:
Example:
if I write want to escape at I have to write \a\t\ but after saving it qtranslate returns \\a\\t.
I've tried to write just at but of course it don't recognize this as escaping non-string text and doesn't add automatically the needed single \a\t.

[johnclause]

Under which plugin version?

[pedro-mendonca]

Sorry, I'm using version 3.2.9.1

[pedro-mendonca]

If I include these \a\t in the settings for the pre listed languages in qtranslate.php it works just fine with the data it injects to the database after reset, the problem occurs when I update the Data format in the form.

[johnclause]

This one is terrible. Seems like there is ongoing WordPress discussion on magic quotes, see for example, http://wordpress.stackexchange.com/questions/21693/wordpress-and-magic-quotes. WP adds magic quotes to the POST data. Anyway I did some fix, which may get things messed up again later if WP changes its code. I pushed it to the latest master branch.

Please, close the issue if it tests ok.

Below is the description copied here from the code, just to keep a record:

  /**
        @since 3.2.9.5
        In earlier versions the 'if' below used to work correctly, but magic_quotes has been removed from PHP for a while, and 'if(get_magic_quotes_gpc())' is now always 'false'.
        However, WP adds magic quotes anyway via call to add_magic_quotes() in
        ./wp-includes/load.php:function wp_magic_quotes()
        called from
        ./wp-settings.php: wp_magic_quotes()
        Then it looks like we have to always 'stripslashes' now, although it is dangerous, since applying 'stripslashes' twice messes it up.
        This problem reveals when, for example, '\a' format is in use.
        Possible test for '\' character, instead of 'get_magic_quotes_gpc()' can be 'strpos($_POST['language_date_format'],'\\\\')' for this particular case.
        If Wordpress ever decides to remove calls to wp_magic_quotes, then this place will be in trouble again.
    */
    //if(get_magic_quotes_gpc()) {
        if(isset($_POST['language_date_format'])) $_POST['language_date_format'] = stripslashes($_POST['language_date_format']);
        if(isset($_POST['language_time_format'])) $_POST['language_time_format'] = stripslashes($_POST['language_time_format']);
    //}

[pedro-mendonca]

It's working fine now. 👍
I didn't know about the discussion, but it has been working fine in the WordPress core options page in Date Format custom option.

[pedro-mendonca]

One more doubt on this topic:
What's the difference between using these two format systems?
http://php.net/manual/en/function.strftime.php
http://php.net/manual/en/function.date.php

For what I've seen, both can do the same.
WordPress points here http://codex.wordpress.org/Formatting_Date_and_Time to help to set the options for Date Format and Time Format in Options > General, and basically uses the php function date() syntax.
Is it necessary to have both options?

After checking on this (backslash) issue, a lot of options of qtranslate_options.php need to be changed from de and der to \d\e and \d\e\r.
To end this, all the preset options are in strftime. If assumed to be like WordPress core, it can be changed to above mentioned Formatting Date and Time guidelines.

[johnclause]

I am not really sure, this piece came from the original qTranslate, and touched twice for bug reported, including yours. I think the whole date/time format framework needs to be re-designed by the newer standard, but this is low priority for now.

After checking on this (backslash) issue, a lot of options of qtranslate_options.php need to be changed from de and der to \d\e and \d\e\r.

Are you sure about this? It was there for ages. Will we potentially break anyone? If you are sure it is needed, would you mind to PR on this?

[pedro-mendonca]

I didn't saw this because I had author metadata hidden in my theme.
You can check it easily on post data and using each and every different setting on the preset list.
I've tried with both systems and they seem to work all ok. The letter e is captured as Timezone identifier as in here http://php.net/manual/en/function.date.php

The word de is returned to me as Day of the month+Timezone identifier. It only returns as de if coded as \d\e. The same applies to der.

It's easy to identify this editining one language for testing, pasting all those old strings hardcoded in qtranslate_options.php.

Please check this before accepting the PR, I've already included in a prevous PR earlier today https://github.com/qTranslate-Team/qtranslate-x/pull/107/files#diff-a9d9901d065dd46182dc2bc4043b9ed1

[mirenbz]

Should the format editing through the "Edit language" form be working? I'm trying to set up another language (Basque) and escape characters (\) are converted to literal dashes (\\)...

[pedro-mendonca]

Which version are you using?
I believe it is solved at the moment within current version. @johnclause made a temporary solution since v.3.2.9.5 (d02b5ff)

[mirenbz]

3.2.9 release. Should I upgrade to the latest alpha pre-release?

[pedro-mendonca]

As I wrote above, it's solved since v.3.2.9.5.
As far as I know the latest alpha is working fine (https://github.com/qTranslate-Team/qtranslate-x/releases/tag/3.2.9.8.8). I'm not sure if the pre-release versions are considerably more stable than alpha versions, but you can check here that you have a lot of options since 3.2.9.5 before going alpha, being the v3.2.9.8.1 the latest non-alpha:
https://github.com/qTranslate-Team/qtranslate-x/releases