mkk84

It was only a font color ‘issue’.

Fixed it with custom style:

.search {
    color: black;
}
.current-item {
	  color: white;
}

Adding define(‘NGG_JQUERY_CONFLICT_DETECTION’, FALSE); to my functions.php solved the issue.

Hi,

so habe ich es jetzt auch gel?st.
Ist halt, wie du richtig sagst, ein Workaround.

Danke für deine Zeit!

Hi,

ich nutze den Blockeditor.
Hier ein Screenshot von dem Feld, das ich meine:
https://abload.de/img/fromclipboard6mkho.jpg

Hilft dir das weiter?

• This reply was modified 4 years, 9 months ago by mkk84.
• This reply was modified 4 years, 9 months ago by mkk84.

Hi

I probably misunderstood this functionality then:
Yes, the search term is highlighted on the summary page of the results. I expected it to be highlighted within the actual post/page/… that was found. When I click on the link of a search result, I see the ‘plain’ post/page/… without any highlighting.

Hi @timrv

your advice to use “Events > Settings > Bookings > Booking Form Options > Display login form = YES” works fine but when a user keys in wrong credentials, he gets sent to the backend login.

Is this the intended behavior?

My expectation would be that the user stays where he is and the error messages are presented to him as part of the login form.

Thanks for your quick reply!
– your code is in /child-theme/functions.php (at the very end)
– I moved the po/mo files from /wp-content/languages/plugins to /child-theme/languages/

Debugging shows that $loaded is true:
$loaded = load_textdomain( $text, $mofile );

No comes the weird behavior:
If mo/po files are available in /wp-content/languages/plugins, the whole plugin is translated.
If I move them to /child-theme/languages/ only some terms are translatet. For instance, only “booking” and “settings” from the main menu are translated.

• This reply was modified 4 years, 10 months ago by mkk84.
• This reply was modified 4 years, 10 months ago by mkk84.
• This reply was modified 4 years, 10 months ago by mkk84.
• This reply was modified 4 years, 10 months ago by mkk84.

Hi

For given reasons, I would like to maintain and use my own language files.
@msykes / @duisterdenhaag:
Where do I have to place your code in order to make it work?

Thanks for your feedback.
After hours of testing, I have found the following workaround:
– I moved the files “loggedin.php” and “login.php” one level up
– I changed the login() function in ‘class.simple-wp-membership.php’ to load the moved files:

if ($auth->is_logged_in()) {
   //Load the template for logged-in member
   SwpmUtilsTemplate::swpm_load_template('../loggedin.php', false);
} else {
  //Load the login widget template
  SwpmUtilsTemplate::swpm_load_template('../login.php', false);
}

With the files in the new location, every change gets reflected instantly; just as expected.

Well, now the mandatory pages were created and ‘Page Settings’ are fresh as well but the rendered view of, for instance, loggedin.php remains as is and no code changes I make in this file gets reflected in the browser.

Even after uninstallation, (among others?) the following fields within table ‘wp_options’ remain filled:
– swpm_db_version
– swpm-settings (containing all ‘Pages Settings’)
– swpm_private_key_one
– swpm_email_activation_lvl_2
– swpm-messages
– swpm_alr_settings

I found the following in the installation routine:

if (empty($installed_version)) {
  //Do fresh install tasks
  //Create the mandatory pages (if they are not there)
  ...

I will now remove all fields from ‘wp_options’ and install again…

Sorry for my late reply!

What I did:
– Uninstalled ‘Simple Membership After Login Redirection’
– Uninstalled ‘Simple WordPress Membership’
– Manually dropped table ‘wp_swpm_membership_meta_tbl’
– Manually dropped table ‘wp_swpm_membership_tbl’
– Manually dropped table ‘wp_swpm_members_tbl’
– Manually dropped table ‘wp_swpm_payments_tbl’
– Installed ‘Simple WordPress Membership’
– Installed ‘Simple Membership After Login Redirection’

What I noticed:
– The plugin did not create the pages it created when I installed it the first time
– The plugin’s setting remained. For instance, “settings | Pages Settings” where I set, for instance, the ‘Edit Profile Page URL’ to ‘../membership-login/’ was there. All other settings changed by me are ‘remembered’ as well.

This implies the uninstallation does not work properly, right?

By the way:
I created a fresh user and loged in. Despite of the php-code of ‘/simple-membership/views/loggedin.php’, I still see the altered loggedin.php I created weeks ago.
Again: I can even remove all files within ‘/plugins/simple-membership/views’ and the plugin remains functioning.

To start with, I would like to understand why the plugin’s uninstall does not work correctly. This behaviour prevents an all-fresh installation.

By the way:
When calling the file directly (/wordpress/wp-content/plugins/simple-membership/views/loggedin.php), the latest file is viewed. I just pasted a “echo ‘test’;” into line 2… works as expected.
When calling the file through the wordpress system, nothing is shown…

And with this, the hoster argues it’s not his problem.

I am in contact with the hoster who argues they do not support web development. They said, I should get in contact with the plugin support.
I am on a shared server (no Cloudfare).
I told them how disappointed I am… as this looks like a chaching issue.

But speaking of removing the plugin:
Should the db tables get purged and all configuration removed?

I know it does not make sense…

Of course, I have removed and installed the plugin before:
– Deactivate the plugin
– Remove the plugin
– Install the plugin through wordpress

No change!
Not sure what removing the plugin is supposed to do. I expected all data and db-tables would be removed. After reinstalling the plugin, though, all my users are still there, db-tables did not get removed or purged, and even my plugin configuration is there.
Is there any way to REALLY remove everything so a completely new install is possible?

I still think it’s a caching issue… the only thing that wonders me: why is your plugin the only one that’s affected?