maxoud

The activation keys are valid for ONE (1) year as from the date of purchase.

This text was found in the General terms and conditions of sale.

Likely your Content Security Policy (CSP) blocks inline scripts (doesn’t allow unsafe-inline). Allowing unsafe-inline endangers security, though.

It’s possible to securely allow inline content through SRI hash or nonce (not the one WordPress-native), but there is no any acceptable way to implement them without manual changes to the Core and plugins on every update.

The only way is to change the CSP policy to less secure allowing unsafe-inline script and style sources.

See CSP Sources for hash and nonce and SRI.

P. S. Use Web Developer’s Console (Ctrl+Shift+K or Cmd+Shift+K) to check what scripts have been blocked and which directive is responsible for that.

• This reply was modified 4 years ago by maxoud.
• This reply was modified 4 years ago by maxoud.

When you use two dropdown switchers, they happen to have identical attributes (<select name="lang_choice_1" id="lang_choice_1">). That’s the reason only one (the first) JavaScript block works.

You have to construct your own dropdowns. Use pll_the_languages( array( 'raw' => 1 ) ); to get language names, codes, URLs etc, copy and modify JavaScript generated by pll_the_languages() (see the source).

There is the wpml-config.xml file where you can specify how to handle post meta translation. You can choose between ‘translate’, ‘copy’ or ‘ignore’ for each custom field. For more info see Polylang Documentation.

Also, make sure Custom Field checkbox is unchecked at Languages → Settings → Synchronization.

pll_copy_post_metas and pll_translate_post_meta filters also can be useful.

• This reply was modified 4 years, 10 months ago by maxoud.
• This reply was modified 4 years, 10 months ago by maxoud.
• This reply was modified 4 years, 10 months ago by maxoud. Reason: Corrected the mistake
• This reply was modified 4 years, 10 months ago by maxoud.

Is it possible to use a static front page?

People unable to read documentation will always face nonexistent problems.

Hi, Barry!

I was trying to get rid of slugs translations in the plugin’s original the-events-calendar-ru_RU.mo. I didn’t need them to be translated.

The above seems like what you want to have in place

Yes, I already had it, but the translation was not acceptable for me.

potential for WordPress to download an updated translation file, overwriting this one

That’s why I wanted to override the original the-events-calendar-ru_RU.mo the way it can’t be overwritten by WordPress. The way offered in the Knowledgebase didn’t not work for me.

P.S. I was trying to bring together The Events Calendar and Polylang with no luck and decided to write the Polylang-compatible, built to my needs plugin.

See this post.

WordPress, Events Maker, Polylang – everything is up-to-date.

1. I’ve made a clean WordPress install with Events Maker and Polylang plugins enabled.
2. Created required pages under Events Maker -> Settings -> Display.
3. Created two languages, EN (default) and RU.

No other default settings were altered.

Also, I’ve tried to Hide URL language information for default language in Polylang’s URL modifications settings but it does not have an impact on the issue.

The simple method to fix this issue is to remove month, list, day, today, upcoming and past translations from the *.mo file of the corresponding language in the /lang directory of The Events Calendar plugin. These are around line #7070 in the *.pot file.

P.S. Notice that entries to remove are NOT capitalized, so double check.

• This reply was modified 8 years, 1 month ago by maxoud.

@fabino, you’ll loose your hack after the plugin update. Never edit WordPress core files or plugins developed by others not you.

The plugin already throws 403 Forbidden HTTP status code:

wp_die( __( 'This has been disabled', 'wps-hide-login' ), 403 );

Complemented:

– Custom Taxonomy Order NE

@mra13 I don’t want to generate controversy but despite of HTML5 here is action attribute definition from 16 years old W3C recommendation for HTML 4.1:

action = uri
This attribute specifies a form processing agent. User agent behavior for a value other than an HTTP URI is undefined.

Empty action is not a valid URI so you can’t be sure what’s the action will be assigned by UA. While HTML 4.1 covers pretty wide browser range.

@mbrsolution, thank you, but that documentation is on the wrong topic.

Here is StackOverflow question on the same topic I mention and here is the solution if you have problems with non-empty form action.

It’s not a big problem but it’s the only validation error shows up on my pages (and not only my). Validator error is:
Bad value for attribute action on element form: Must be non-empty.

@mbrsolution As of the date of the version 4.1.7 it’s not resolved.