?eslav Przywara

@mtyldesley

There is a special CSS rule in your theme stylesheet that makes the background image visible:

/* Sections */
.page.et_pb_pagebuilder_layout #main-content {
	background-color: transparent;
}

Otherwise, main content has white background that overlays the background image:

/* Containers */
#main-content {
	background-color: #fff;
}

There seem to be no such rule available for post pages, so you have to add it yourself:

.single.et_pb_pagebuilder_layout #main-content {
	background-color: transparent;
}

But I don’t see any connection to Polylang in your case. Do you use it all? ??

Cheers,
?eslav

Hi Mark,
I’m glad I can help.

Btw. you might want to mark the thread as resolved.

Greets,
?eslav

Hi Mark,

Unfortunately your theme is not a free one, so I cannot check the code.

Since the title is in header part of the page, my guess is that theme authors are not using the standard get_the_title() function that works only in the loop, but instead retrieve page title with other means that seems to not work well with Polylang.

Could you try to determine which file is used to display the header part and paste the relevant code here? You may try to perform full text search over theme files and look for any file that contain “Header_wrapper” (it’s the ID of the header element).

Hi,

Why do you think this is a problem caused by Polylang? Does the background image show if you turn Polylang off?

Cheers,
?eslav

Hello Mark,

– What theme do you use? Do you have the same problem if you switch to default WordPress theme like Twenty Sixteen?

– Polylang creates new page for every language, so this is right. There’s a handy language switcher in the top admin bar that you can use to display pages only from given language.

Cheers,
?eslav

Hi,

If you can access and edit your .htaccess file, try to delete everything between the following two lines: “# BEGIN All In One WP Security” and “# END All In One WP Security”.

Alternatively, you can try to rename .htaccess file, so it want be evaluated by your webserver and see if it helps.

Greets,
?eslav

Hi Benjamin,

You probably haven’t read plugin description:

This plugin disables the new emoji functionality in WordPress 4.2.

Note: Emoticons will still work and emoji’s will still work in browsers which have built in support for them. This plugin simply removes the extra code bloat used to add support for emoji’s in older browsers.

The plugin does not disable emojis as such. It removes extra code that helps to display emojis in older browsers. A lot of website owners that do not use emojis (or extended Unicode) on their websites consider these extra scripts an unnecessary bloat.

You cannot disable emojis the way you described it. If you don’t want emojis in content area then simply do not use them.

Greets,
?eslav

I’m glad I could help!

I would suggest to try something like:

function my_function() {
  // as above
}

function my_custom_fields() {
  // Get translated IDs.
  $idLangs = my_function();

  // Define your custom fields - you can use data from $idLangs here...
}

add_action('plugins_loaded', 'my_custom_fields');

This code works the same way if included in must-use or normal plugin.

It seems the problem you have is that you want to fetch data from Polylang before it is loaded. Must-use plugins are loaded before normal plugins, so if you call my_function from must-use plugin code, you will not get any results.

One solution is to move your custom fields declaration from must-use plugin to normal plugin. Even then I recommend to wrap the code that runs my_function in function hooked to plugins_loaded, because you have no way to determine in which order WordPress loads your plugins.

Yet another solution is to install Polylang as must-use plugin, but I have no experience with that and don’t know if Polylang works that way.

Do you have Polylang installed as must-use plugin as well? If not, you should hook my_function to plugins_loaded action instead of muplugins_loaded.

Also, I recommend (whenever possible) to use functions that are part of Polylang API – this way you’re less likely to find out that your code does not work after you update Polylang in the future.

Try the following code:

function my_function() {
  global $idLangs;

  // Sanity check
  if ( !function_exists('pll_languages_list') ) { return; }

  $myFrenchId = 1696;
  foreach ( pll_languages_list() as $slug ) {
    $idLangs[] = pll_get_post($myFrenchId, $slug);
  }
}
add_action( 'plugins_loaded', 'my_function' );

Hi Manhy,

Are you aware that you overwrite single variable ($idLangs) again and again in your for loop? This way, print_r($idLangs); prints only ID of translation in the very last language that is returned by $polylang->get_languages_list().

Also, it would help if you add some context to your code. Where is it placed? From where is it executed: global scope or a function?

Greets,
?eslav

I just noticed this has been fixed in version 3.4.0 – thanks!

Hi Mateusz,

I don’t use Polylang for a long time, so I don’t know if anything changed, but I noticed that I have to define menu for every language I have on the site (under Appearance > Menus). And every menu has to link to proper pages/posts (ie. in the language of the menu). In other words, Polylang does not seem to translate navigational menu items for you – Chrystl, can you confirm?

I think you might have the same problem on your site (despite that my site has html lang attribute set correctly). Try to create one menu for Polish (with Polish pages) and assign it to Primary Menu Polish position (or what’s your theme name for the menu position). Then do the same for English.

Greetings,
Czes?aw

Hi Andreashej,

The code you pasted here will not work, because you’re applying “display: inline” to <ul> element (ie. the list), not to list items (ie. <li> elements).

Try to add the following snippet to your CSS:

li.lang-item { display: inline; }

If it doesn’t work, probably your theme has its own styles for menu items with higher precedence.

Greets,
?eslav