chrismask

I think this is the error i was getting everywhere

I have told you, its never seen on new devices enetering site for first time. It was only on device that visited site on specific time when i upadated the plugin. It was like device cache got infected with something that couldnt load any css nor js from site (saying 404 error) while they existed and the scripts were correct and even seen on code browsing of chrome dev tools, but still couldnt load them and site was blank and completley unresponsive. Also after clearing both page and object cache numerous times, the issue couldnt be fixed (new ?ver= ) of scripts were loaded after page clearing and still the same problem. I got rid of the problem when i manually cleared all browser history and cache which is obviously not a solution since many customers still see the page like this and think its a website error and just abandon it. Just check what could be the problem with service worker and how the scripts are loaded on the browser or something.

I have activated the plugin again. After 2 days and after clearing cache multiple times, it wasnt fixed, on specific urls it had the same problem of downloading empty file. I cant send you url because it was only for logged in users, and also it was only on my browser because i had visited an “infected” by superpwa page on specific time i cant determine. Now i have cleared browser cache and works. Please find the solution to the problem.

Yes i have seen that it’s difficult to download directly from js and browser. I had seen that there is a way of creating the file put it on folder and get user the url to download automatically.

So a way of doing it is creating the file putting it inside the plugin folder so the user downloads it and then delete it or something. Anyway, you know better. Thanks

Hi
Okay I understand about alerts.
I have some other questions
1. The Javascript file contains all css, displayed text etc leading to very large js file over 50kb. I have disabled it from running on all pages and only use it where it’s needed. You shall somehow enqueue it only where the shrotcode exists.
2. Message not available to iPhone chrome, use safari. This message is displayed for both apple and outlook calendar which is not a good approach, if users can’t add to calendar with Apple or outlook, then these options shouldn’t be visible at all and could be confusing saying use safari because chrome can’t download from url etc.

Everything else is awesome. Good job

Hi, can we add this wp_rank_math_redirections_cache to object cache to improve performance or even add the whole rankmath table to object cache since it doesnt have user sensitive info?

Okay please fix this issue its bloating my error logs every day

Of course it’s an issue. Just notify the developers

Update:

2nd thing I did was deactivating all insert database capabilities by inserting return on the beginning of every function id insert-update class file and some files on class-query that insert strings in database. The same can happen easily, one simple option of Disable new strings database insertion or something. After, I have removed all useless strings from gettext and dictionary table. On English (default) I removed all untranslated strings, and on my second language all strings that I didnt need. On create_gettext_translated_global function which sets all gettext strings as global (completely unneeded), in foreach I skipped all untranslated strings,. On process_gettext_strings I skipped all new strings insertion calling and some other small modifications.

These two functions, process_gettext_strings and create_gettext_translated_global account for almost all speed of the plugin and these two simple modifications speed up the plugin 10 times for english (with very small gettext table) and 5 times for greek (with 4000 rows of translations). Now translatepress plugin php runtime from 0.4s went to 0.05-0.1s, which is a great improvement without big compromise, and can easily be achieved with some small improvements. I am sure the plugin creator can do this with 1 hour work, and can even improve it further with some further modifications.

As of now, I havent seen any visual problems, translations work well. Some of my observations are: 1. You firstly need to stop all gettext table insertions before stopping all gettext strings from being loaded into global variable in create_gettext_translated_global, since other functions detect uninserted strings and insert them again.

I know about this data-no-transaltion thing, I didnt really understand if it was a joke or something, of course I am not going to put data-no-transaltion in all thousand urls or image urls that the site has, it may break things, hurt seo or whatever.

As mentioned in the documentation, the external links are detected for the possibility of changing the URL in a different language. We had a lot of users requesting this in the past, as well as image translation, so those were implemented.

So you ruined your plugin speed and didnt even think about an option of opting out of these, for the 0.1% of usage of translation, which is for images and external urls?

Another possibility is to have duplicate entries in your database which might affect your loading speed. You can use the Remove duplicate rows option from TP Settings –> Advanced tab to clear them and you should see improvements.

I have used this on staging site, several times, and it always has problems. It starts and never actually ends, of course I am not going to use it on production site. Also, i dont mind deleting all useless strings from database, I mind having them generated again after 10 minutes or something, as it has already happened.

The increased loading speed may be due to a lot of JS content. We have a listener for Javascript strings that when it detects a text change on the page (say a particular JS script adds a notice), we query the server for a translation. This ajax call is also fast as it doesn’t go through the normal WordPress ajax, however, it can be run intensively when there is a lot of traffic to your website. The good part is that you can disable this functionality from TranslatePress -> Settings -> Advanced tab.

I have told you many times, I am talking about TTFB or the time the server is generating the html document to send to the browser, on uncached pages, which is a lot due to the translatepress plugin. This has nothing to do with my javascript files and I have optimized them in any case. About the script you say, is it only for detecting changes on strings, or is it needed for fetching already translated strings from trp tables? Is it trp-translate-dom-changes.js? Update: This option disables dynamic tranlsation completely, even translated strings dont work. I just want to disable bloating the database.

Now, regarding your suggestions for improvement, our dev team will review them. However, the way WordPress environment works make it pretty difficult to separate different type of content, for example, to not detect a string at all if it has a link behind it. This may lead to wrong detection of the desired content which will cause other problems that are difficult to control. Okay, just create an option not to generate any new translation string at all. I have finished (as well as the 95% of users of this plugin) all translation and dont need all this slow functionality to run on each page, just give me the option to stop generating ALL types of new strings. If I want to continue translating, I can disable it, so simple.

To sum up, you are unable to fix anything, just tell me the file this string generation happens.

• This reply was modified 1 year, 9 months ago by chrismask.
• This reply was modified 1 year, 9 months ago by chrismask.
• This reply was modified 1 year, 9 months ago by chrismask.

Can the developers answer this topic? I have told you I have tested all possible advanced options, have gone through all documentation and searched all google, and at the same time I had automatic translation on? I am saying every string generated by site and even server (even open:atom urls are generated and i only use atom on filezilla) goes to original_strings and dictionary table and they have bloated completely the database with 95% of them being useless urls and image urls, this has nothing to do with translation apis, and of course i have it disabled.

• This reply was modified 1 year, 9 months ago by chrismask.

Are you going to fix it or suggest a way so i can fix it? At least give me the functions where these operations happen, I am a premium paying user.

I have tried putting domains like https://www.google/*, my site, even https://* or whatever, tried /wp-content/ to stop generating infinite image links (like who even translates image url?) and doesnt work at all. A simple option to stop filling the dictionary and originalstrings table would be very good.

1. Stop new translations
2. Dont translate links
3. Dont translate images
4. Cleanup database from useless content.

At least the 1 is mandatory and shall be implemented soon, at least give us a hook or tell us the function in which all these strings are generated.

Also, a good addition would be to stop looking at dictionaries and original strings enormous tables on page generation time, that searches all this enourmous dictionary table and loads the translation that matches. This makes each page slower without good reason. Why wouldnt this plugin be simpler since 90% of people that use it, do it just to translate gettext strings, and use the language switcher. I just want only these and not a hundred more useless features that make every page slower.

• This reply was modified 1 year, 9 months ago by chrismask.
• This reply was modified 1 year, 9 months ago by chrismask.

I am referring to all links. Of course I have put there all domains that get generated, doesn’t work at all. But my issue is not this. I just want the translation to stop. I have translated everything I wanted. Why isn’t there an option to stop putting all strings in the database, in the first place? At least give me a hook or the function this takes place so I deactivate it.

Good. No Divi isntalled, never did.