Forum Replies Created
-
-
Thanks for the clarification and the great idea! Then i will remain the only one who will see that ugly toolbar 🙂
Did not notice this implemented feature, it is kinda hidden.Hi there,
Would like to remove that ugly black WP Admin & BuddyPress Toolbar from my site for the general public and all the users who can not publish posts (therefore they do not need to get the links to the back-end).
Actually removing it is quite easy but then people do not have the login/registration link (unless i put WP’s meta section on the side bar).
And here comes the feature request:
What if you would extend Kleo’s my account menu item to show a login/register link (or icon) for users who are not logged in? This way the public and plain subscribers would never see the ugly toolbar, but they could still login or register easily.Perhaps you could even include options for which user roles should be the admin toolbar rendered (for example admins, authors need it even if it is hidden from plain subscribers).
I think this would be a great addition and is pretty easy to code.
Hi Catalin,
Thanks for the answer!
Meanwhile a had to modify the logic of registration process and the default english text of buddypress does not make sense any more on my site. Found out that I can not modify the original source text in a po file (and newer BP versions will contain the default text in the source code).So in my case i have to stay at my dirty solution. After all it works just fine.
You can mark the topic as solved.Regards,
PeterHi Catalin,
My suggested tweak works. Will do it as a solution for now.
By the way made some typo with the parenthesis. The right code is:
if (ICL_LANGUAGE_CODE == “sk“){
//here comes the slovak text
}However please try to investigate why the modified po file from kleo does not do the job. That should be the clean and proper way to do it.
Regards,
PeterI think i will try a dirty solution.
Will modify members/activate.php in the child-theme like that:
if (ICL_LANGUAGE_CODE == ‘sk’){
//here comes the message in slovak
}
if (ICL_LANGUAGE_CODE == ‘cs’){
//here comes the message in czech
}
if (ICL_LANGUAGE_CODE == ‘en’){
//here comes the message in english
}Though the clean solution would be to get the job done by kleo’s po file, i will try the above solution and inform you about the results.
Hi Catalin,
Thanks for the answer!
Yes, i already tried to change that text directly in the php file (did it in the parent theme) however only temporarly. Had 2 reasons for that:
1. It would be lost when kleo gets updated. It can be avoided if i do the same in my child-theme as you suggest.2. This way however that text would be slovak even if a user registers in english. So that way english users would not understand that text.
My site is multilingual and more languages will be added later to it.
Do you think if i modify that string directly in the php of the child theme, it would be translated by WPML? If you are sure sure i will modify it accordingly but it is a production site where i would not like to test.This behaviour is really strange as all the other registration-related strings get translated by WPML from other po files. So i just do not understand what is the problem with kleo’s po file.
Regards,
PeterHi there just want to report that finally i could solve my issue.
Before i tried to reset everything from an initial backup and then upgrade all the themes and plugins, but this method did not work.
Then i got so frustrated that i completely deleted all the files and the database from the server, and reinstalled everything from scratch. Now everything is fine, but can not explain why.
Okay i tried it on a staging server where WP is in multisite and with multi network plugin is also activated.
Today or tomorrow i will test all that on a clean plain installation of WP that was never modified in any way and must have a clean database as well. Will let you know about the results.(But even that would be strange if deactivated plugins could cause a conflict like this…)
Yeah, doble checked it. If only WPML3.1.6 or only revslider is active, then theme option panel works just as expected.
When they are both active they have some conflict behind the scenes that knocks out theme option panel of kleo. However a user in the front-end can not notice anything from it. Did not face such a bug until now…pretty strange for me.Some update:
Schumy could solve another issue by just deleting and reinstalling revolution slider.
Have just tried that. Right now i have revolution slider v4.5.95 installed but (was v4.5.9 before) but kleo’s theme option panel is still broken while WPML v3.1.6 and revslider v4.5.95 are both active.
This means if i want to change my theme settings, have to deactivate revslider for some minutes. Strange anyway.Hello Schumy and Abe,
Well not sure if this is the right topic but i simply could not open a new one.I have had problems even with KLEO v1.5 when revolution slider v4.5.3 was active.
The major problem was that kleo’s theme-settings page was broken while revslider was active.
Now in KLEO v1.6 we have revolution slider v4.5.9 bundled, but the same issue is still there.I remember i noticed my issue some days after i installed WPML v3.1.6. Since then i have several minor issues with other themes and plugins. So i can think of WPML v3.1.6 has some unexpected changes under the hoods, did not test and try however. The developer of BusinessFinder theme suggested me to revert back to WPML v3.1.4 to solve some issues, but i really do not like the idea to use outdated plugins so i did not try. But i am sure they did and they had a good reason for that. Am sure they will have to update their theme to support WPML v3.1.6 and if so then it might be true even for KLEO.
Hope this info helps and gets us closer to a solution.
Regards
