b-smark

Hi

good, seen & updated ??

thank you @sergiorcs

Hi,

yep that’s it.
Almost: the box appears ‘open’ on the right side, no right border https://151.80.148.45/foobar/gt-on-pri-menu-1.PNG
Also it’s below the bottom line of the menu, adding margin-top:-28px to gtranslate_wrapper aligns it for desktop but then appears over the menu line in mobile view.
The ‘nice’ menu is somewhat tricky to get it right.
Since I added ‘via Google’ I set overflow-x:auto and height:5px for the switcher to allow for full string panning – pri-menu forces bigger fonts.
The plain dropdown fits nicely instead, both desktop & mobile.
Overall, can live with that, might be theme-related.

thanx a lot

1. ” it is good to know who is contacting us” trojans coders’ argument. You have to ask, user decide not you.
2. of course site admin can do extra things as it see fit, if decides to install a plugin. Don’t know if there’s a standard way to hook to privacy/cookies plugins, having these installed and such other plugins which load regardless is kinda a conflict that calls for admin to patch here and there. I’m fine at the moment just adding ‘(via Google)’ after lang_name.
3. will open bug issue & upload screenshot

thanx

yep. But I was thinking something like (dunno WP internals etc so dunno if it’s feasible): new table id/login,hash or augment users table like :

user_login
user_username <- new field
user_nicename
display_name

seems that the mechanism is, username -> user_login, lowercase(username) -> user_nicename, any/combo of {username, first, last} -> display_name. Theme seems supposed to use display_name.
Now, if a plugin does: user_login -> user_username, somehash(username,timestamp)-> user_login and then user is displayed such its hash to use as new login, all should still work fine and usernames even collected before the hashing from the pages wouldn’t be useful (anymore) because the valid login now are the secret hashes (of course assuming login is always within an encrypted/protected channel).
The only issue seems that users can choose their user_login (hence the hash) as display_name too, eluding the trick, so either a plugin can restrict such choice or site user policy must be strict and enforced.

yeah, problem is that a site should have never blogged with posted-by exposed, let alone by admin users, but themes opt for that is way too drastic, usually all/none meta while one would like just the author name not exposed.
A solution could be to map login-name -> hash, users would have to use that hash to login, valid login-names would be those hashes then, instead of the public author name/nick
I guess custom login url plus the other opts reg wp-login.php and wp-admin is the way to address the issue, at the moment. The hash login would be kinda per-user custom login URL.

Ok, thank you for the answer.
I’ve checked a few themes, not all have such option, so that’s another criteria for choosing a theme

your .zip seems to contain exactly CF7 latest 4.5.1 from this site.
Perhaps your alarm is a bit excessive, you should provide more & better infos – what you mean by ‘hacked’ and how, which are the traces, site config, plugins etc
WP itself and any piece added can have bugs of course and audit of src code is always good & welcome. Report of exploit like this are not much helpful though.

Regarding being left without contact form, there are many alternatives for you to try

nope, my bad:

Eventually I got access to maillog and seen the culprit was the email input in the form.

sorry for the noise :/

hi

perhaps make langs as install options? that’d save wp.org’ rules and allow users to get just what they need

thx

tried comment 9 to no avail – giving up then, sorry. Perhaps I’ll try once again on occasion of another WP update.

thanx anyway

Thank you Josh, I’ll try the procedure as soon as I have the chance.

yes, I fully flushed UTMCE then tried fresh install of WPE.
I reported after trying all such things

thanks

Hi Josh,

thank you for reply. Yes, I’d like to get it working, site’s editors were used to UTMCE.
Though I went through threads about apparently similar issues and did not see solutions, let alone a clear pattern to fix/avoid the bug(s).
Point is, that it’s the software that must take care of all the housekeeping stuff, in DB, caches, cookies etc etc to ensure installation / upgrades succeed smoothly – not the users / humans.
I don’t care if any such tricks like a magic combination of browser, cache cleanup, DB reset etc etc might WFM – I don’t want a chance to hear from editors “hey, where’s my page?!? where are the buttons?!?” once again.
Perhaps it’s an intrinsic bug of WP, but usually most plugins run smoothly across WP and own upgrades (if compatible) or at most need de-activation / re-activation – that is, a bulk admin-only 1-time action.
UTMCE has always been a nightmare, and I see WP Edit inherited these traits.
So I’d like to install it, but not till these issues are handled properly and duly by the plugin, without bothering the humans, except for dashboard-level 1-time admin-only action kinda like mentioned.

Thanx

BTW, all icons are icon fonts, like most of WP by now.
Too bad.

thanx for the tips, I’ll try them out as soon as I can