[Resolved] Translation is not automatically linked to the original blog post

Thank you for your patience and cooperation.

I've tried several thing without any luck. So I need to escalate the issue to our 2nd tier team for a detailed investigation.

For this purpose, I need to take a backup of the site after remove the unnecessary stuff like inactive plugins and themes to keep the package size smaller.

Is this OK for you? Please let me know.

Thank you for confirmation, I've escalated the issue to our 2nd tier team.

Although I've created a package after removing unnecessary plugins and themes but it is still 4GB+, which I am also trying to download.

Please keep the staging site access open. I'll update you as soon as I hear back from the team.

Thank you for your patience and cooperation.

Our team investigated the issue and wants to understand that if there were any recent changes in server or site's environment? Because if it has been working previously, why it is not working now?

We can see it works with CTE but not when using the WordPress Editor but we cannot catch any significant errors.

They further noted:

We have added a php-info.php file to the staging. You can access it at:
hidden link

According to the info there are quiet many PHP functions disabled, that can cause such unexpected behavior:

exec, passthru, shell_exec, system, proc_open, popen, show_source, apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_getpwuid, posix_uname, pclose, dl, diskfreespace, disk_total_space, pcntl_exec, proc_close, proc_get_status, proc_nice, proc_terminate, symlink, link, pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, highlight_file, lchgrp, lchown, prog_get_status, getmypid, getmyuid, getmygid, getrusage, getmyinode, get_current_user, libxml_disable_entity_loader

The client should revise php.ini for issues.

Many of them are used for system-level operations, and while WPML doesn't directly depend on all of them, their absence might impact underlying processes or interactions with other plugins.

So they suggest to check with your hosting or service provider and see if they can enable and/or provide any technical information. Here are WPML's minimum requirements https://wpml.org/home/minimum-requirements/, which may also be helpful for the above mentioned.

Please let me know.

Thank you for the updates. I'm checking with our 2nd tier team and 'll update you accordingly.

However as per my understanding, the strict-origin Referrer-Policy HTTP header in browsers prevents leaks of private data by only sending the origin in the Referer header for cross-origin requests. This policy is designed to protect user privacy by not sending the full URL, which may include more data than is necessary. For example, the full URL may include the path and query string, which could be used to access private data.

While, the Permissions-Policy header in HTTP is a security header that lets you control which browser features can be used in a document or within any <iframe> elements in the document. It can help restrict unauthorized access or usage of browser features by web resources, and can ensure user privacy. For example, you can use the Permissions-Policy header to control whether the current page and any pages it embeds have access to the user's camera, microphone, and speaker. You can also prevent external <iframe>s from using browser features.

So I believe, these headers may be the problems but not so very sure. I'll get back to you accordingly.