These are all signs of a javascript conflict in the admin. You’ll probably need to progressively deactivate other plugins to find the culprit. Start with plugins that do something in the admin section.
Same problem here. Ended deactivating all plugins and no solution.
Would removing it manually from the database table (wp_participants_database_groups) work? Previous deactivation of the plugin, off course.
You can delete it from the database directly, but the problem will show up in other ways until you know what the issue is. It’s necessary to look at the PHP error log to see what’s happening to prevent the plugin interface from working.
According to the IT responsible there is no PHP error showing in the log.
OK, well it’s probably a javascript error or a security restriction. The thing to do now is to open your developer’s console and look for either a javascript error or network error when you try to delete a field or group.
Related.
I too have an empty group that I can’t delete (reappears as soon as I click [Update Groups]) Tried deactivating all other plug-ins and re-trying with same effect.
Also… I removed several fields that I decided against using. They no longer show up under Manage Database Fields but they *do* show up in the Participants Database table (using phpMyAdmin). Might this be related to why removing the group doesn’t “take?”
BTW, is it ok to drop the “deleted” fields from the Participants Database table?
+1 Here. I have no other plugins enabled, no javascript errors in the console and no PHP errors being logged.
My Environment is:
Home URL: http://localhost:8051
Site URL: http://localhost:8051
WP Version: 3.9.1
WP Multisite Enabled: No
Web Server Info: Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.5.9
PHP Version: 5.5.9
MySQL Version: 5.6.11
PHP Locale: decimal_point: .thousands_sep: int_curr_symbol: currency_symbol: mon_decimal_point: mon_thousands_sep: positive_sign: negative_sign:
WP Memory Limit: 40 MB
WP Debug Mode: No
WP Language: Default
WP Max Upload Size: 2 MB
PHP Post Max Size: 8 MB
Max Input Nesting Level: 64
PHP Time Limit: 60
PHP Max Input Vars: 1000
SUHOSIN Installed: No
SMTP: localhost
smtp_port: 25
Default Timezone: Default timezone is UTC
Roland,
I found the issue. Line 159 of manage-fields.php looks for the case:
'delete_' . $PDb_i18n['group']
In my case, $PDb-i18n[‘group’] returns “Group” with an uppercase G. The AJAX call in manage_fields.js is passing the value of $thing, which is set to “group” with a lowercase g, so the case doesn’t match, thus the php code skips the $wpdb call to delete the row. It doesn’t return an error, so the javascript reads a success and removes the row from the HTML table on the page. When you update groups or refresh the page, the row comes back because it was never deleted from the database.
I just wrapped a strtolower() function around the case and it works as its supposed to. You may want to implement a more elegant fix, but I’m up and running fine for now.
For those that are interested simply change line 195 of manage-fields.php from:
case 'delete_' . $PDb_i18n['group']:
to
case strtolower('delete_' . $PDb_i18n['group']):
Thanks, I’ll look into this. The values of the internationalized string depends on your translation, but it should match no matter what the translated string is. It’s supposed to match the key, not the internationalized string, so I must have messed up.
BigTuna’s trick worked for me as well.
GreatBigTunas solution worked for me as well.
worked for me as well. But I cannot add fields to new created groups, why?
Yes, that’s the bug. It’s fixed in the next release.
acdigital, what happens when you try to add a field to your groups?
Hi xnau, nothing happens, you type the field name, click ADD FIELD, the page reloads with no new field created.
Could be a security exception, I guess. best way to check for that is to open your browser developer tools, then watch the network panel when you try to add a new field.