new tag created with wrong slug #366
Comments
|
Do you use QTranslate-Slug? |
|
No... It's another plugin? I use qtranslate-x only |
|
Than that plugin is not compatible with q-translate-x On Thu, Apr 28, 2016 at 3:17 PM, Dmitry notifications@github.com wrote:
|
|
I do not use QTranslate-Slug |
|
Is this only happening for custom types? Which plugin do you use to manage custom types? |
|
I have not tried this with a regular post... I will try it today. |
|
Hi Dmitry, could you test if your problem solved here: https://github.com/qTranslate-Team/qtranslate-x/archive/stable.zip ? |
|
Hi John, I've tried it with a regular post - the same result, a new tag created with a wrong slug. |
|
Link I gave you is the latest updated https://github.com/qTranslate-Team/qtranslate-x/blob/stable/qtranslate.php#L6 You probably looked in readme https://github.com/qTranslate-Team/qtranslate-x/blob/stable/readme.txt#L7, which I have not finalized yet. The changes made which should target your problem is ad28ac4 ;-) |
|
Ok, I've tried this 3.4.6.8 |
|
Are you sure? Did you do deactivation/activation? I cannot reproduce it anymore. You may need some clean up on older tags. Did you try a brand new tag and post? |
|
Hi Dmitry, would you have time to test it deeper soon enough? I want to release 3.4.6.8, but I wish to make sure that you are ok first. I cannot reproduce the problem anymore by the steps you listed. Am I doing something else than you do? Could you think of a better way for me to reproduce if the problem is indeed still there? Thanks a lot. |
|
Hi John, sorry, I was away from my computer for 2 days... What I found out:
I'm glad that with new tags it works, but what should I do with my old tags? |
|
Wow, sorry about this. I guess, the easy way would be to fix it in db. I assume you know how to edit database, right? Fix table wp_terms first. Edit names and slugs as you wish them to be. Names should be in the default language without any "[]", same way as they would be without qtx. Then copy content of option 'qtranslate_term_name' into a text file to be able to edit it. It is a hash with keys to be the term name and value is a hash of "xx" => "name translation". Make sure the keys are the same as names in wp_terms table. I assume you know how to edit hashes in db? The tricky part is to adjust the length if you change some string. If you think it is too complex, send me .sql file with wp_terms and value of option 'qtranslate_term_name' via qtranslateteam at gm ail d c om. I will try to fix id and may come up with some cleaning script, as I assume some other people would have this problem too. Interesting that you are the only one so far to notice this trouble. I guess, people do not use tags much, or do not translate them. |
|
Hi John, I've sent you a mail with .sql files. |
|
Hi, Dmitry, we are working on an option to clean up term translations, as it seems to be a problem inherited from old qt-. Now WordPress did so many changes, that old way, qt- was dealing with term translations, is totally obsolete now and needs to be re-designed anyway. Does this issue hold you from going ahead with your development? Your db file shows just a few broken tags, which you may edit manually in a normal way at /wp-admin/term.php page and it should correct the problem from now on. Is that right? |
|
Hi John, no, this issue does not hold me. I just found out that I need regularly check the terms after my editors made some changes in the posts. I takes 5-10 minutes to clean up after them. But certainly I prefer to resolve this problem in the future and forget about it. Could you give me some clues how manually correct my old tags? Just "Edit Tag" and then press "Update"? |
|
Yes, I think just making sure that all the values, including slug, are correct at term.php and pressing "Update" should fix database entry. All ids and relationship with posts are staying the same this way, only tags names and slug get adjusted in a correct way. I did not try though. What does that do for you? You should use LSB mode at term.php. Raw Editor Mode is discovered broken at term.php and we are working on fixing it too. |
|
Hi Dmitry, could you please test https://github.com/qTranslate-Team/qtranslate-x/archive/stable.zip as much as you can? This should be a fix for your issue, as well as editing of tags in Raw Editor Mode, etc. It should even allow you now to add a new tag on Apply database operation "Clean Legacy Term Names" from page Please, try really hard to break it for a few days and let me know if you find problems. Thank you very much. |
|
I have published pre-release with that version: https://github.com/qTranslate-Team/qtranslate-x/releases/tag/3.4.6.9 |
|
Hi John, |
|
Any news? |
|
I hope you are ok, Dmitry, are you? Have you gotten a chance to test at least a little bit? |
|
Well, I do not see how this explains the problem. I knew that part of the code. On the very first call to the get_the_terms or to get_term the same cache is created for each term object. During this first time, it should pass through our function, which adds additional property i18n_config and changes the term name. These changes get stored in cached object and then subsequent calls use the same cached object with properties already adjusted. That is the theory, and this is how it works on my testing server. I am not sure what exactly is different on your server, I am only very glad we did testing on your server before releasing this code. It could have broken like a half of our users ... We need to figure it out. I am starting thinking that it may be easier if you could setup an admin access for us including FTP? Maybe to a testing server which shows the same problem? It would take some time for you to set it up for us, but it might be less time for you to spend than to finish troubleshooting on your own? What do you think? Is there an easy enough way to set such a server instance up? Or maybe you could use plugin like Duplicator to create a copy of your site (with the minimum content) that we could instantiate on our local server? Meanwhile I'll try to run some tests with calls to get_the_terms, maybe I would be able to reproduce the same problem. |
|
John, I do not see any problem to give you access to my server. |
|
Thanks a lot! Safe form here: https://qtranslatexteam.wordpress.com/contact-us/. |
|
I've sent via the form. Please confirm that you got it. |
|
I added the credentials to my main site because I cannot reproduce the problem on Staging... which leads me to idea that it's connected with the cache of WPEngine which is not active on Staging. |
|
Ah, finally we are getting somewhere, so it is case 4, external caching? Is there a way to enable caching on staging? Could you talk to the provider if they can use locale as a cache key as well? Is there any control panel for caching, with some options to adjust? |
|
WPEngine is a very big provider... there is not any control of their caching... I do not think I can make any influence on them... |
|
Does not hurt to ask, they should have a solution for multilingual sites. But let us first make sure that it is indeed from their caching. Cache should go by URL, right? If you turn off option "Hide URL language information for default language.", then URL will define the language uniquely. Does this help? |
|
I will ask them. |
|
We found out so far, that the problem was coming from older version of yoast-qtx integration plugin. Dmitry, did you manage to find more problems on further testing? |
|
John, It looks like the problem is still here. |
|
Hi Dmitry, Any luck to reproduce it again? I played a bit more and could not reproduce it. Did you try to test all other stuff? Are you working on this site or is it more or less done and no further plans to improve for now? |
|
Hi John, I can reproduce it again. The same place, the same tag... Your fix does not help. This site is more or less done, I only improve some things and add new posts. |
|
"Copy From" fills empty fields only, otherwise it can be damaging. Clear the text of field wanted before copying. I cannot reproduce in any of my browsers. Same page? What did you do before you could reproduce it again? |
|
try the following: http://truewine.ru/en/movie/giacomo-conterno-barolo-1955/ switch to RU switch to EN then press "Next" on the picture when loaded switch to RU in my browser the tag Barolo is does not change to Бароло |
|
if it does not work try to move between posts with "Next" and "Previous" buttons and switch the language |
|
Yes, I could reproduce now. Wow. That one is probably case 4 now, advanced caching. This is not reproducible on staging server either, is it for you? I'll try to investigate for more details. Thanks! |
|
Did you figure out "Copy From"? Is it helpful? |
you know, I implemented "Copy from" for myself one year ago. My implementation was not "general", it was very connected with my site (so I decided myself which fields I would like to copy). But I have a "visual confirmation" in my implementation: when I press button - the fields changed. I still have a chance to reject these changes - I just need NOT TO PRESS the "Update" button. in your implementation if the field is not empty - nothing happens. NOTHING. If I get message that "the fields should be empty" - maybe it would be helpful. But sometimes I NEED to REWRITE the fields after some changes in the post. In my implementation I press the button "Copy" and then if I'm sure - "Update". In your case - too much work to empty all fields. Maybe it will be helpful for you. |
But I cannot understand - why the "Title", "Description", "menu" and all other things are switched with "advanced caching" and only tags - NOT? |
|
That is what needs to be figured out, and that is what I meant by "advanced caching", which might be done on per-object base, not per-link base. We should find the true cause before jumping to a conclusion in any case. |
My idea was that if you have something in the field, then you do not want to copy other language, you simply edit what you already have. I saw the use of it only when a new translation is started. Occasionally, if user really wants to redo one particular field over, then they may empty it before pressing "Copy From". Overwriting all the fields every time is too much, since user will want to change just one field in most of cases, unless a completely new translation is being started - and then all MLFs are already empty to begin with. Having a separate button for each field is too much too, as it is a feature of rather rare use. How do you suggest to implement it? |
|
I could reproduce it a few times. Then switched yoast plugins off and then could not reproduce it anymore, which gave me a suggestion that the problem is still in yoast plugin. I turned them on again, and then still cannot reproduce it no matter what I tried. What a heck that could possibly be? I notice that you use I am not sure for now how to proceed. It is very hard to troubleshoot when there is no a consistent way to reproduce ... |
|
I turned yoast off again and was able to reproduce the problem at some point. Let us keep it off for now, would you mind? It simplifies the execution a little bit. I'll do more research. |
|
After more research, our current theory is that it is persistent object-based cache issue coming from file |
|
I have just activated yoast plugins back, since I realised that we should now test full configuration now to see if disabling of cache helped. BTW, please, pay attention to the change in speed. Does that advanced caching make a considerable difference? Now your site should be felt slower, is it indeed? |
|
Any news? |
|
Do we have a confirmation, that it is ok now with cache off? |
|
I did not have much time these days to test it. |
The problem is the following:
I have tags which are linked to post with custom type (in my case 'movie').
For example tag with Name
[:en]Barolo[:ru]Бароло[:]
and with Slug in English
barolo
When I change something in my post with this tag (the content for example) and then update it
Could you check it? It's very annoying to re-check all tags and delete/relink them...
The text was updated successfully, but these errors were encountered: