Forum Replies Created

Viewing 15 replies - 1 through 15 (of 286 total)
  • Thread Starter Steve Taylor

    (@gyrus)

    Many thanks.

    Thread Starter Steve Taylor

    (@gyrus)

    Thanks. I removed your plugin, deleted the mystery group types, then edited the actual group types to make sure the fields were properly filled in using the BP core taxonomy. Now everything works using just BP core functionality.

    Thread Starter Steve Taylor

    (@gyrus)

    I need to delete the mystery ‘false’ group types. I have 4 ‘true’ group types (those we have always used, with group associations indicated in the Count column of the group types admin list). But there are 8 ‘false’ ones. They have no group associations, and they seem to have been created based on data from normal posts. They are all being output as tabs on the front-end groups page.

    For example, one ‘false’ group types has the Type ID and Slug ‘get-involved’. This is also the slug of a key landing page on the site. When I delete the term under Groups > Group types, the page gets deleted as well. How can I purge these ‘false’ group types without deleting the content they seem to be connected to?

    • This reply was modified 7 months, 3 weeks ago by Steve Taylor. Reason: typo
    Thread Starter Steve Taylor

    (@gyrus)

    In wp_posts I find 4 posts of the type bp_group_type – these are our group types.

    In wp_term_taxonomy there are 12 items with taxonomy bp_group_type. They relate to terms in wp_terms. There’s the 4 actual group types, plus 8 others which, from the slugs, seem to somehow have been copied from posts of other types (e.g. blog posts). All items have the name the same as the slug.

    Please let me know how I might tidy this corrupted data up, I’m wary of doing it without fully understanding how your plugin manages the bp_group_type posts and the bp_group_type terms.

    Thread Starter Steve Taylor

    (@gyrus)

    More info if it helps: all the group types tabs on the front-end, as well as having no labels, have the same URL: /groups/type/bp_type_directory_slug/

    Thread Starter Steve Taylor

    (@gyrus)

    OK, sorry, it looks like part of the problem is we added some code in December because of the problems we were having with your plugin:

    function my_bp_loaded() {
    
    	// Disable core group type taxonomy
    	// Seems to clash with Create Group Types plugin, temporary hack
    	remove_filter( 'bp_get_default_taxonomies', 'bp_groups_register_group_type_taxonomy', 1 );
    
    }
    add_action( 'bp_loaded', 'my_bp_loaded' );

    When I remove this I can access the Groups > Group Types admin screen. However, while we had about 4 group types, there are 12 listed. I can see which are the 4 ‘actual’ types via the ‘Count’ field, only 4 of them have any associated groups.

    On the front-end interface where the tabs should appear, all 12 are shown, without labels. Presumably this is related to the items not having anything for the ‘Name’ field in admin.

    Is there a conversion process I need to follow? Should I simply delete the 8 ‘false’ group types and edit to include the ‘Name’ field for the 4 ‘true’ types? This seems like a way to do it, but I’m wary as I’m not sure of how this data’s being managed between the plugin and BP, and I don’t want to mess the data up.

    Thread Starter Steve Taylor

    (@gyrus)

    No luck. Deactivated, tried Groups > Group Types, same ‘Invalid taxonomy’ error. Reactivated and tried again, same error.

    Thread Starter Steve Taylor

    (@gyrus)

    Thanks for the reply. As stated above, when I navigate to Groups > Group Types I get an error screen saying, ‘Invalid taxonomy’.

    Thread Starter Steve Taylor

    (@gyrus)

    Just to let you know, since part of our client’s site is broken due to this issue, I tried rolling your plugin back version by version, to see if I could find the last working version. However, the version where I started seeing the group type tabs on our front-end interface was 2.3.0, which is before you introduced support for BP 7 – and then I’m facing the same issues I outlined in the initial post here again.

    Obviously I don’t want to roll back BP as well. Ideally, since it looks like you’re having problems with the plugin, we would try to move away from it and use the Group Types functionality in BP 7 core. However, given our current schedule, and not knowing how much work this would involve, I’m hoping you’ll be able to see where the problem is and release a fix before then.

    Thread Starter Steve Taylor

    (@gyrus)

    Hi, I just noticed that our page with group type tabs is now no longer showing the group types. This is locked into BuddyPress 6.4.0 still, from before you released a fix for BP 7 compatibility. I assume since our BP version is locked, a further update to the Group Types plugin caused this issue?

    Locally I’ve updated to BP 7 but the issue persists. In admin when I click on ‘Settings’ for the Group Types plugin on the plugins page, it goes to wp-admin/edit-tags.php?taxonomy=bp_group_type and I get an ‘Invalid taxonomy’ WP error.

    Any idea how to fix this?

    Thread Starter Steve Taylor

    (@gyrus)

    OK, it seems that on previous projects we had to fork WP PageNavi to make it work with SWP_Query – and I’d forgotten to use that forked plugin.

    Working for now but – I think the changes we made in the fork were pretty simple. Any chance of WP PageNavi adding SearchWP support?

    Thread Starter Steve Taylor

    (@gyrus)

    I’ve just realised that when we took our BP plugin out of being locked to 2.9.4, and updated to the latest and allowed auto-updates, the latest at the time was 6.3.0.

    The new core management of group types is part of 7.0.0, which has just been released. This is why our problems suddenly appeared this week.

    As far as I can tell, the core group types taxonomy clashes severely with this plugin’s post-type-based group types system.

    Is this going to be a case of the plugin being updated, or we should migrate to the core system? If the latter, will there be a tool to help migrate plugin data to the core system?

    For now I’ve rolled us back to 6.4.0, which seems to be working OK, but it’d be good to nail down the situation here.

    Thread Starter Steve Taylor

    (@gyrus)

    Thanks for the quick response.

    We initially forked to manage some complex debugging – I think we needed to log certain things where there weren’t hooks available, and the code needed to sit there and run for a while to catch an unusual problem we were having.

    But since then there’s been some tweaks, nothing major I think.

    One was rejigging of the markup in ass_default_subscription_settings_form() – basically our styling couldn’t work with labels outside radio inputs, they needed to be wrapped around the inputs. It actually looks like you’ve changed in this direction since we forked. Same situation with ass_group_subscribe_settings() as well I think.

    The main other change was more fine-grained control of $link in ass_group_notification_activity(). It looks like this code has changed significantly in the meantime, enough so that I can’t see what change I would suggest to the current plugin. Looking at 3.7.2, I replaced lines 145-152 with this:

    https://pastebin.com/wEJ3beeN

    The function ass_generate_notification() which $link is passed to doesn’t seem to be used anymore? bpges_generate_notification() instead? I assume $link could be easily filtered here?

    I’m not sure why the script isn’t enqueued based on the plugin’s settings.

    I want to add some code to conditionally dequeue it, but if I hard-code the condition, I’ll have to remember to change the code if the admin settings get changed.

    Ideally the condition would be based on the plugin’s admin settings – but why doesn’t the plugin itself do that?

    Thread Starter Steve Taylor

    (@gyrus)

    Hi, Laragon is a XAMPP-like dev environment for Windows. I can appreciate not using Windows for production, but I’m currently stuck with a Windows laptop for local dev and I’ve not heard of anything that might impact multisite per se in those terms. I’m running Apache.

    Anyway, it seems to be working with those lines commented out. It just seemed worthwhile seeing if anyone knew why that might be, in case I hit other issues along the way without those lines. I’ll post if I find anything.

Viewing 15 replies - 1 through 15 (of 286 total)