Hey,

I have a weird issue with simple-press on a client website: The URL of the form is translated into german (it is a german blog). Thats why the saving process doesnt work. Here the wrong url:

/wp-admin/admin-ajax.php?action=profile-save&form=accounteinstellungen&userid=397&_wpnonce=0169894455

And it should be this:

/wp-admin/admin-ajax.php?action=profile-save&form=account-settings&userid=397&_wpnonce=0169894455

I couldnt find any translations for this. Do you have an idea how I can fix this issue?

Thanks,

Mike

Well SP does not translate it. And I know nothing in WordPress that would translate it. In fact nothing should translate it as it would no longer work - as you find.

Do other WordPress Ajax calls from other sources get translated like this? The same would apply - they should then fail.

I think you need to start by looking closer to home. What about WP plugins? Do you have any of those to do with automated translations?

what version of simple press?  and wordpress?  I saw this happen once before on a much older version of simple press...

can you try going to forum - toolbox - housekeeping and reset the profile tabs...

Thank you for your replys!

SimplePress is uptodate. And there were no other translation plugins.

But: I found the issue in the database. I changed the slugs manually in the table "sf_meta".

meta_type: profile
meta_key: tabs

I could not figure out how the wrong slugs came to the db. When are the slugs written to the db? Is it save from updates in the future?

Few minutes ago i've debugged the code to find the issue we're discussing here: https://simple-press.com/suppo.....de/page-2/  and found that there's a translation problem on form name that doesn't allow the ajax call to work properly:

on line 55 of sp-ajax-profile-save.php:

if (isset($_GET['form'])) { if (isset($_GET['form'])) { $thisForm = sp_esc_str($_GET['form']);

but sp_esc_str doesn't translate the GET variable so the switch below doesn't work returning an empty result.

then i've noticed this post and i don't feel alone now 

The question is why are Mike's profile strings translated in the first place? SP does not do this. These form name strings are not in the PO files. And to answer MIke's question - no - they are not protected from future updates. A few of our plugins will re-run the code to rebuild the sfmeta record.

@mr-papa - so are you saying that you have seen these strings translated before?

I also checked the po files and could not find any translations for them.

Is it possible that the slugs are taken from the titles? It was always the title in small letters with a minus instead of the space.

@yehonal I might be wrong but think the ajax-save file takes the slug from the form url which is already wrong. So there we already have the translated slug.

@yellow-swordfish Is there a hook where I could temporarly change the slugs to the right one after every update? Probably not the cleanest solution but to make it save for the next updates it could be a workaround.

I've noticed that even if i change the language site in english, all strings are displayed in english except profile menu item on left (screenshot)

so i think that meta-values are already translated in db (maybe a wrong upgrade?)

@wpmike did you fix it?

all my users can't update their profiles from many days :-/

For a plugin that is awash with hooks I am surprised to find there is not one there. That's OK as we can add one easily enough. But don't misunderstand me... normal SP updates will not rebuild the tabs record - they only change when one of plugins adds a new tab on activation. And actually - this does not rebuild the whole record - just adds a new entry or two.

On the slug/title question, it uses the 'slug' element of the array you found in the sfmeta table. And that is because the title CAN be translated but the slug should never be. 

By the way - I am aware that @mr-papa said above that he recalls this happening before a long time ago but i have to say that I can not and it is, I believe, a unique issue. We have lots of users in Germany and Italy (for example) who do not report such a problem and many have bene users for some years. And this is in my view we need to look a little closer to home to see if there is some unique circumstance in your WP site that is responsible in some way.

I will talk this over with Mr Papa later today...

Ok thanks @yellow-swordfish 

Meanwhile is there a way to restore original meta-values for core metadata?