g4rf

So far everything seems well configured.

We use a lot of plugins but it is normal and it suddenly becomes this behavior.

That’s the point to get in: If you remember, what you have changed (plugin update, theme update, …), then we may find the solution. As WP Multilang wasn’t updated since 2019, it’s more likely, that another plugin/theme broke the functionality. Again: Please deactivate all other plugins for testing and check, if this behaviour of WP Multilang exists. If it works, enable one plugin after another and check WP Multilang.

This is not standard behaviour, normally this works very well even with many languages. To solve it, we need more informations on it:

• Please clarfiy first, that you do not working with several tabs open and editing different languages in there, because that won’t work (it’s not a bug, it’s by design).
• I guess you are on the latest available version of the plugin?
• Which languages you are using? Would be helpful if you can post a screenshot of your Languages tab of the WP Multilang Settings. Please open the single language settings for this.
• Do you use other plugins that may interfere with WP MultiLang? If you are not sure, deactivate them and have a look, if the problem still exists.

Best, Jan

Hello Smith,

what do you mean with “Portfolio translation”? Is “Portfolio” a custom post type by a plugin?

Best,
Jan

Dear drugoinafanya,

did you solve the problem? If not, more information is needed.

Best,
Jan

Hi @erolsk8,

I checked it now with a new bunch of 72 files (7 videos and 65 images). It worked, but not completely. ??

I tried it 3 times and the progress bar stopped around 30 imported files. For the last import I let it go (doing some other work) and as I tried just again to import the other half, it said that already everything is imported.

Also it didn’t show 10 images in every batch round: It started with 10, than it showed e.g. 19, than e.g. 27 – it seems not to have a pattern in it.

So: The progress bar stopped viewing the results, but the files were imported properly.

Some remarks:

• I didn’t find the set_time_limit in your code. Did you do something else (apart from the manual batch size setting)?
• I guess, that there is – beside of the max_execution_time on my server – another issue with displaying the correct number of imported files. But that is just a guess and I didn’t dig deeper into it.

So far I think with the manual batch setting the issue is solved. If there are any display errors while counting, than I have no clue, where to start.

Thanks for debugging this issue! ??

• This reply was modified 1 year, 10 months ago by g4rf.

Thanks for the code update, I’ll check this today or tomorrow. I think, that this will solve the issue, even if the whole process will last longer because of more network requests.

I’ll checked your code now and my idea was this one:

In your MediaSync.class.php in line 813 there is the call to the WordPress core function wp_insert_attachment(). This call may last too long per image so that with 5 images the whole script execution time hits max_execution_time in php.ini. If you now add a call to set_time_limit() before the wp_insert_attachment() call (and so reset the execution time), then every wp_insert_attachment() has (in standard confs) 30s to execute. That should be long enough for one image.

With this solution you won’t need too reduce the batch size, as long as one call to wp_insert_attachment() is faster than 30s. You can theoretically even raise the batch size to 100 or 1.000 – but this will lead to long lasting http requests, but never hit the max_execution_time.

Best, Jan

Thanks a lot for the suggestions, but it’s definitely not a problem of the client side. It’s about importing around 20 to 40 images, so in whole about 1 to 2 minutes – nothing that leads to a sleep, loosing internet connection or a session timeout.

As I reported above, raising the max_execution_time in php.ini solves the issue. So my guess is:

The algorithm tries to import 5 images at a time. As WordPress generates different image sizes, it tooks sometimes more than 30 seconds (standard max_execution_time) to finish these 5 images (more than 6s/image in average). If this will happen, the server aborts execution and no response is send to the client. Because there is no response, the javascript won’t go on with the next images.

To dig a little bit deeper: In my instance WordPress will generate 5 scaled versions of an image. As the server is optimized to reach out static content (cache system), resizing images is not the fastest process. So generating 5 scaled version of a large image may be longer than 1 sec per scaling and we hit the 6 sec per image limit easily.

A possible solution on the server side (as I said above): After processing 1 image (of 5) just call set_time_limit(). This will reset the execution time and the script has again 30 seconds to process the next image. I did not read the source code of Media Sync, so maybe this is already done; in this case it needs futher fine tuning.

Best and thanks,
Jan

The bug is not a bug and not a problem of Advanced Post Block. If custom post types are not capable of the block editor (not registered for REST), they are also not shown in properties of other blocks. That might be happen with old plugins or themes or if this is intended for a special custom post type.

Maybe you can add a hint to your FAQ.

I’ll leave that thread here for documentation and other peoples facing the same problem.

Best, Jan

• This reply was modified 1 year, 10 months ago by g4rf.
• This reply was modified 1 year, 10 months ago by g4rf. Reason: added suggestions to add a hint to the faq

Hi,

if somebody else comes to here: That is not a problem of the map, it’s (mostly) a problem of the CSS layout. The height=100% of the map is working as it should, but it’s relative to the parent container. So: If you don’t give the parent container a real (not relative) height, the browser will calculate it to 0px. I suggest reading tutorials as CSS positioning is not trivial. A good starting point is e.g. https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Positioning#positioning_contexts

Best, Jan

Hi ccmp,

that’s not a problem of this plugin, but a thing of your layout.

I guess you set the map height to 100%, to fill the parent element; that’s correct so far. Now, the parent element has to set it’s height like the block to the left. This depends on your layout and CSS.

A short view on your page shows, that you use Flexbox for layouting in CSS, so this site should help you: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Best, Jan

Hey @govindpp,

in general the language tag for the standard language is not shown. If this is the case on your website, just deactivate Use prefix for language by default in the WP Multilang Settings ? General.

Best, Jan

Hi!

Try to change the Language Code in WP Multilang Settings ? Languages to en-us and see if it’s working.

As a work-around you can use a plugin like Redirection to redirect /en-us/ to /en/.

Best, Jan

Hey!

WP Multilang stores all translations of the title in the title field of a post. That said, the title need’s to be filtered, to use the correct language (or the standard one).

When LinkedIn grabs your site, I assume, it gets the title, image etc. from the header of your website, maybe some OpenGraph tags or other meta tags. It seem’s, that your website uses the raw title of your site in the website head, not the filtered one.

The solution is, to examine, which plugin (or the wordpress core itself) generates the meta tags (maybe Yoast SEO or similar plugins). This plugin (or wordpress by itself) has to be configured, to put filtered titles in the meta tags. This depends on your site configuration – there is no general how-to.

Hope that helps to point in the right direction.

Best, Jan

Solution:
There is the REST API add on. As we are a non-profit organisation, there are at the moment no capabilities to use a payed plugin.

Workaround:
Just call the specific url in an ajax request. It’s not optimal as the server does site generation and this only works without the “use plugin cache” option. But it’s the simplest workaround for now.

Example with jQuery:

var url = "/path/to/page/to/record/a/hit";
jQuery.ajax(window.location.origin + url);

• This reply was modified 4 years, 3 months ago by g4rf.
• This reply was modified 4 years, 3 months ago by g4rf.

I have already disabled all plugins that I’m not using.

I increased the WP_MEMORY_LIMIT to the PHP memory limit of 136 MB, the problem still remains.