codejp3

I think I narrowed this one down some more.

Custom generated files get removed on plugin update. I’ve found myself having to go into BSP and re-click “save options” just to regenerate custom files after an update.

A minor inconvenience for a single site install. A total pain for multisite installs.

I added a plugin_activation hook that will automatically regenerate custom files any time the plugin is updated, for both single site installs and multisite installs.

This will be included in the update I send you later today.

BIG Update coming your way later today…..

You change the message text, and hide it in the “Forum Index” tab (#15):

wp-admin/options-general.php?page=bbp-style-pack&tab=forums_index_styling

Worst case, you could even hide it with just css:

#bbpress-forums .bbp-template-notice {
  display: none;
}

I’m using version Version 1.4.7 of the plugin.

The only change made to it is the one listed above.

FILE: subscriptions-for-woocommerce/admin/class-subscriptions-for-woocommerce-admin.php

METHOD: wps_sfw_options_page

LINE WITH ISSUE (231):

if ( ! $is_home ) {

It’s a nested check, and unless pre-conditions are met, $is_home does not exist when this line of code is reached. That’s why I added the single line at the start of that method to define it as a default prior to any checks.

I deleted my local plugin, re-downloaded v1.4.7, and verified that this line of code does indeed exist,and does indeed kick out the debugging notice that I opened this topic about. In one of my code editors, it shows it as line 231. In another code editor I use, it shows it as line 232. Point is: IT’S THERE, even though you’re telling me it’s not.

I’m going to move forward with this. I found myself stuck in a conundrum when it comes to multisite installs.

Each site has to set BSP settings individually, but the generated files are setup specifically for ONE site. Make a change in one site, it re-generates files based on those settings, which don’t match the settings for each individual site.

I’ve been trying to manage without re-writing the plugin for multisite compatibility, but there’s no way to resolve it except to generate files per-site based on each sites’ BSP settings individually.

I created a new private GitHub repo for this. I’ll send you an invite link when I have something worthy of looking at.

Can you do some further checking on your site to see if it is either a combination of settings in my plugin, or a combination of plugins/theme/child theme functions that is causing on your site ?

Yeah. I’ll see if I can narrow it down some more.

I don’t understand your question because WPS Hide Login doesn’t let ? in secret slugs. They’re removed when settings are saved.

That’s probably the conflict.

The bbpress login function, (specifically the bbpress stylepack plugin) is what is kicking back the “?login=nothing_entered” error when your plugin is enabled.

The bbpress code related to this login issue is:

function bsp_login_failed( $username, $error ) {
	$errors = reset($error);
	$failed = '' ; //just in case nothing is passed !
	if (!empty($errors['invalid_username'])) $failed = 'invalid_username' ; 
	if (!empty($errors['incorrect_password'])) $failed = 'incorrect_password' ; 
	if (!empty($errors['empty_username'])) $failed = 'empty_username' ; 
	if (!empty($errors['empty_password'])) $failed = 'empty_password' ; 
	if (!empty($errors['empty_password']) && !empty($errors['empty_username'] )) $failed = 'nothing_entered' ; 
	$referrer = bsp_current_page_url();  // where did the post submission come from?
   // if there's a valid referrer, and it's not the default log-in screen
   if ( !empty($referrer) && !strstr($referrer,'wp-login') && !strstr($referrer,'wp-admin') ) {
	   //then strip any old referrer requests
	   if (strpos( $referrer, '?') !== false) {
		  $referrer = substr ($referrer, 0 , strpos ($referrer , '?')) ;
		}
		add_query_arg( 'login', $failed );
		wp_redirect( $referrer . '?login='.$failed );  // let's append some information (login=failed) to the URL for this plugin to use
		//wp_redirect( $referrer) ;
       exit;
   }
}

Is there something you can adjust within this plugin to account for the hard-references to ($referrer,’wp-login’) & ($referrer,’wp-admin’), or do you have suggested revisions that should be applied to the bbpress login to allow it to work with your plugin?

Made one subtle change based on your input. Still supplying a post_id, but changing the order of the args so location is first, then post_id. Also changed the “bridge/helper” function values for those two passed args.

Here’s the new branch:
https://github.com/codejp3/bbp-topic-count/tree/propsed-release-2.9-revised

Here’s the side-by-side comparison:
https://github.com/codejp3/bbp-topic-count/pull/2/commits/01a567dd622cbece3e8f1c633af869e5e464c7c3

Here’s the direct download link:
https://github.com/codejp3/bbp-topic-count/archive/refs/heads/propsed-release-2.9-revised.zip

Very minor, but should prevent future issues arising.

Cool!

I’ve already thought about releasing a v2.10

Only change would be how the admin settings are rendered.

Break them out as a template part.

Then in the BSP plugin, if topic counts plugin is active, render the topic parts count template part within BSP. If not active, then render the standard BSP topic count tab.

It would require changes to both this plugin and BSP, but once it’s done, the BSP topic counts tab will reflect the settings saved in topic counts plugin and vice-versa. That way, settings from both plugins “match” and the only difference between the two is whether you have shortcodes or not.

Maintaining the two code bases should be easier, and there would no longer be a settings tab that “does nothing” in BSP when both plugins are active.

Haven’t started on it, but I think that makes sense to implement.

Would it be helpful for me to post 5.1.9 on github and a new branch with these changes so you can compare code, and download the already modified files directly? Test it out with the bbp topic count plugin first and see if it’s helpful. If so, I’ll do the same thing with this plugin.

I re-added you as a collaborator for the repo. Once you accept, you should be able to access the code.

Don’t worry about any tutorials on using the command line push/pull/merge commands. That’s a whole new system to learn. For now, just get used to the web interface. You can see the file structure and access each file.

I’ve added 2 branches.

“Main” is your last release v2.8.

“proposed-release-2.9” is my code changes.

I’ve created what GitHub calls a “pull-request” to merge code and apply the new changes to the main branch. Don’t worry about merging the two. The useful part for you is that you can view a code comparison between v2.8 and v2.9 side-by-side.

To view this code comparison, access the bbp-topic-count repo (accept your invitation and it should show up as one of your repos), and then look for the “pull-requests” tab, and within that tab look for “commits“. Here’s a direct link:
https://github.com/codejp3/bbp-topic-count/pull/1/commits/0176c6871c467b211289361b506349cd136a1e71

You’ll see the exact differences between the two.

You can also download the new proposed v2.9 directly to test it out on your test server before pushing it to the WP plugin directory.

Don’t get caught up on the git command line stuff (2hr tutorial is just scratching the surface) unless you plan to integrate it into your workflow. It takes a bit to get used to.

The web interface is sufficient enough for the purpose of code comparison, and downloading the new version.

I gotcha.

If I do pursue this, the easiest way would be for me to post the current version in GitHub, and then create a separate branch with my code revisions. That way you can see ONLY THE CHANGES between your code and my additions. Would help with the “understanding” part, and save you time trying to figure out what’s different.

For now I’m going to leave this one be.

If others chime in on this topic saying “YES, WE WANT MULTISITE SUPPORT”, then I’ll take the topic more seriously and pursue it.

Two more follow-up issues. One’s an easy fix, the other may be time-consuming to resolve.

1.) The “Report” link “a.bbp-report-link” css selector is missing the initial “display: none;” style attribute so that the select drop-down is hidden until a user clicks “Report”. Easy fix.

2.) The AJAX for reporting posts takes FOREVER.

On a site with php.ini script timeout set to 30 seconds, it consistently takes 30 seconds to “process” the report until the “Your report will be reviewed by our moderation team.” message shows.

On a site with 120 second script timeout set in php.ini, it consistently takes 120 seconds to “process” the report until the “Your report will be reviewed by our moderation team.” message shows.

That seems to be an infinite loop happening with the AJAX processing that the script timeout kills.

The processing actually happens pretty quickly (I can see the _bbp_modtools_post_report & _bbp_modtools_post_report_count meta values show up in the DB instantly), but the AJAX call/response itself doesn’t die() immediately after it’s done processing. Once it hits the script timeout value, THEN it finally dies and the page refreshes with the “Your report will be reviewed by our moderation team.”

This excessive processing time is what led me to find the issue with “Report reason” showing up as the reason a post was reported. The processing takes so long, that I selected different values in the reason select drop-down, and multiple reasons were reported/processed BEFORE the initial AJAX call ever finished.

It’s stuck in a loop somewhere along the way. Script timeout kills it, but 30 seconds, 120 seconds, or whatever script timeout is set to for wait time makes it unusable for front-end users. Especially when changing the select drop-down option within that wait time produces multiple reported post reasons.

This may take a while to debug. If you want some assistance, let me know and I’ll do what I can, but you’re far more familiar with how modtools processes reports than I am.

I wiped all versions of the plugin and started from scratch. 5.1.9 does seem to be applying styles now.

I’m going to chalk this up to an issue on my part due to background sync-ing between my code editor and the site since I’m knee-deep in development of a site right now.

Marking as resolved.

HOWEVER:
Testing this issue led me to find consistent 404 not found errors in my log for both bspstyle.css and bspstyle-quotes.css. Of course they disappear when a user actually hits “save” in the tabs for those files to be generated, but until then, they don’t exist and kick out 404 errors.

I’d suggest either shipping the plugin with empty bspstyle.css and bspstyle-quotes.css so that there’s SOMETHING there to enqueue, or adding a conditional “if file_exists” check before enqueuing those files.

ALSO:
FYI, I still have to manually apply these fixes to 5.1.9:
https://www.ads-software.com/support/topic/classes-bsp-one-half-bsp-one-third-missing/

https://www.ads-software.com/support/topic/reply-button-missing-closing-div/

https://www.ads-software.com/support/topic/uncaught-referenceerror-jquery-is-not-defined-38/

https://www.ads-software.com/support/topic/moderation-tools-issue/

One more follow moderation tools issue.

If I select a report topic/reply reason, but change it back to the default “Report reason” before ajax gets a chance to process it, or do a page refresh with one option selected and change it back to “Report reason”, then it gets reported with the report type of “Report reason”.

To prevent those from getting logged as reported topics/replies, I just added another condition check within the report.php file, handle_report_post() function:

	public function handle_report_post() {

		check_ajax_referer( 'report-post-nonce', 'nonce' );

		$post_id = (int)$_POST['post_id'];
		$type = sanitize_text_field( $_POST['type'] );
                if ( $type !== 'Report reason' ) {
                        $this->report_post( $post_id, $type );

                        _e( 'Your report will be reviewed by our moderation team.', 'bbp-style-pack' );
                }

		die();

	}