GermanKiwi

Hi @platypus424, I just came across this thread and the function you’ve provided in the top post is incredible – an absolute life saver for me!

I’ve just added your function to a new snippet on my site, along with a second function to add your code as a new sub-menu page.

I also made a few minor tweaks to your function to add some help text and horizontal lines, as well as displaying the snippet names when they don’t have an existing title (eg. “Untitled #29”).

So for anyone who is interested in a complete snippet, which will add a new sub-page called “Display Line Numbers” to your admin menu (inside the Snippets menu), then please paste the code below verbatim into a new snippet. Set the snippet to “Only run in administration area” and save it, and then look for the new sub-page inside the Snippets menu on the left.

@bungeshea maybe this could be added to a future version of the plugin itself as a new feature? ??

function snippet_line_search_submenu_page() {
	add_submenu_page(
		'snippets',
		'Display Snippet Line Numbers',
		'Display Line Numbers',
		'manage_options',
		'snippet-line-number',
		'lf_admin_show_snippets_Nth_line',
	);
}
add_action( 'admin_menu', 'snippet_line_search_submenu_page', 99 );

/*
 * Show the Nth line of all active snippets
 * (I put this function in a custom admin menu using add_submenu_page() )
 */
function lf_admin_show_snippets_Nth_line() {

// Default to 2 (where I put the code description)
	$line_number = $_POST['line_number'] ?? 2;
	$lines = '';

/*
* Show the results (when 'Show' button is pressed)
*/
	if ( isset( $_POST['show'] ) ) {

		// $ids, $multisite, $args
		$active_snippets = get_snippets( array(), null, array( 'active_only' => true ) );
		foreach ( $active_snippets as $snip ) {
			$s = $snip->get_fields();
			$title = empty( $s['name'] ) ? sprintf( __( 'Untitled #%d' ), $s['id'] ) : $s['name'];
			$lines .= '<hr><p><a href="'.admin_url( '/admin.php?page=edit-snippet&id='.$s['id'] ).'" target="blank">'.$title.'</a></p>'.PHP_EOL;
			$code = explode( PHP_EOL, $s['code'] );
			if ( (int)$line_number <= count( $code ) ) {
				$lines .= '<pre><code>'.trim( $code[$line_number-1] ).'</code></pre>'.PHP_EOL;
			}			
		}
	}

/*
* Set the line number to show
*/
	echo '
<div class="wrap">
	<h1>'.get_admin_page_title().'</h1>
	<p>This will display the contents of a given line number for all of your active snippets. You can use this to help identify which snippet is causing a particular PHP error on your website.</p>
	<p>For example, if you receive a PHP error similar to this, which mentions the <strong>snippet-ops.php</strong> file, it means one of your snippets is causing the error:</p>
	<p><code>Undefined variable: xyz in /wp-content/plugins/code-snippets/php/snippet-ops.php(446) : eval()\'d code on line N</code></p>
	<p>Then you can enter the line number from the error message into the field below, and look through the results to find which snippet contains the text that matches the cause of the error (eg. "xyz" in the above example).</p>
	<hr>
	<form method="post" action="">
		<p>Line number to show: <input type="text" name="line_number" value="'.$line_number.'">&nbsp;
		<input type="submit" name="show" value="Show"></p>
	</form>
	<h2>Results:</h2>
	'.$lines.'
</div>';
}

Thanks, much appreciated! ??

Hi @wpforchurch, thanks for the quick release of 2.16.6 to fix the issue of the missing notes!

Unfortunately there is still an unresolved issue here.

The key change you’ve made in 2.16.5 was to remove the text field for the Sermon Notes and Bulletin meta fields. Those text fields allowed us to manually enter the URL of a PDF file that was not located in the Media Library. I myself have hundreds of PDF files attached to 10 years’ worth of sermons on my website, and none of them are in my Media Library – they are all located elsewhere, and I have manually pasted the URL of each PDF file into the text field belonging to the “Sermon Notes” meta field for each sermon.

However, your change to 2.16.5 means this is no longer possible for me.

Even worse, it means I can’t go back to older sermons and edit or change or remove the URLs from the sermon note PDFs there, because this field is now gone.

I’ve explained this problem in more detail in your FB group here:
https://www.facebook.com/groups/wpforchurch/permalink/4033988993298615/

I would greatly appreciate if you can resolve this by returning those essential text fields back, so that users like myself, who can’t/don’t store their PDFs in the Media Library, can continue to use Sermon Manager. In the meantime I’ve had to stay on 2.16.3 and I’m unable to upgrade to the latest version.

Please also note that I’m a licensed Pro user.

Thanks for your support!

Hi @hikinmike – just FYI – I’ve just checked the plugin you shared via Dropbox, and it most definitely is version 2.16.1, not 2.16.3 ??

The version is confirmed as 2.16.1 in the changelog.txt, readme.txt, and sermons.php files.

I actually still have 2.16.3 installed on one of my sites, and the plugin is correctly labelled as 2.16.3 there, which also confirms the one you’ve shared is not that version.

It’s not a big deal at all though – rolling back to 2.16.1 is still useful – I just wanted to let you know! ??

Thanks! That worked a treat. ??

Yeah but you can only roll back to 2.15.15 which was released ages ago. All of the versions released since then are not available on the Advanced View page for some reason.

I just updated to 2.16.5 and got the same result: all existing bulletin and sermon note fields are gone! Very frustrating.

Wow, thanks so much for your speedy response and fixing it so quickly! I’ve just updated to 3.1.6 and I can confirm that the filter is working correctly now. ??

Hi Arno, I’ve encountered a problem when using the lbwps_enabled filter:

So I added the function you provided above to my functions.php (exactly as you provided it, with nothing changed). And I checked and confirmed that it was working correctly: all pages which previously loaded the PhotoSwipe resources (JS/CSS files), no longer loaded them anymore, and all pages which previously didn’t load the resources (eg. because the “Disabled” checkbox was checked) now do load the resources.

Then I edited a test gallery page, and checked the “Disabled” checkbox in the PhotoSwipe metabox. This should now have the effect of being “Enabled”, because it’s inversed.

Then I confirmed that the JS/CSS files were being loaded on that test gallery page, and they were. So far, so good.

However: when I click on an image on that page (which is linked to the URL of the JPG) – it results in the page freezing/locking up, and the Chrome console shows this error:

Uncaught TypeError: Cannot read property 'firstChild' of null
    at Object.getChildByClass (scripts.js?ver=3.1.5:1)
    at Object.init (scripts.js?ver=3.1.5:1)
    at l (scripts.js?ver=3.1.5:1)
    at HTMLAnchorElement.<anonymous> (scripts.js?ver=3.1.5:1)

However, if I remove the function and uncheck the “Disabled” checkbox (ie. reverse everything back to normal), then the images on that page do open into the PhotoSwipe lightbox correctly. So the plugin does work the normal way, but not when this filter is being used.

Does the error above, from my Chrome console, tell you what is going wrong?

Hi Arno, sorry for not replying sooner. Thank you very much for creating the Github issue for this request – I appreciate it! Yes, I understand that it’s not a high priority and you have other issues that would take precedence.

Thanks also for the tip about the lbwps_enabled filter. I’ll look into that in the meantime. Although in the long run it would still be nice to have this feature “officially” included in the plugin GUI, at least so the metabox checkbox label can be changed from “Disable” to “Enable” to avoid confusion. ??

Thanks so much – greatly appreciated! ??

Hi Arno,

Thanks for taking the time to explain these points! And indeed I’m already familiar with how browser caching and HTTP connections work in this regard. ??

You’re certainly right that PhotoSwipe can’t automatically determine whether it’s “needed” on a given page. Other plugins (eg. form plugins) are able to do this because they use shortcodes, or other methods, to insert themselves onto a page, and those methods can be detected by the plugin itself, which it then uses to automatically enqueue the scripts and stylesheets on the page in question. However, PhotoSwipe doesn’t work that way and therefore wouldn’t be able to do this automatically – it would only work manually, eg. via a checkbox on each page. But my reason for mentioning this point in my previous message was just to illustrate that the norm is for plugins to only load their resources on the pages where they are needed, and not site-wide, for the sake of not loading resources unnecessarily. That is the general recommendation for plugin behaviour.

It’s true that HTTP/2 allows multiple resources to be downloaded in parallel inside a single connection with the server. However, HTTP/1.1 doesn’t allow this, even when using Keep Alive. Keep Alive allows a single connection to download multiple files, but they need to be downloaded one after the other, not simultaneously, due to “head-of-line blocking”, which is one of the problems with HTTP/1.1 performance. One solution is for the browser to open more than one connection to the server, but most browsers set a limit on the number of simultaneous connections to the server. So with HTTP/1.1, the more page resources (JS, CSS etc) there are, the slower the page load time will be. HTTP/2 solves this by truly allowing multiple resources to be downloaded simultaneously inside a single connection to the server.
https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference

However, my main reason for asking for this feature is because of the total size of these PhotoSwipe resources. They amount to 105 KB, which is quite a lot, especially for slow mobile data connections. Even if they are able to load simultaneously via HTTP/2, it nevertheless adds a not insignificant delay due to the size of the files. In other words: it’s not about the *number* of resources – which could be reduced with a plugin that merges JS and CSS resources into a single file, as you suggested – rather, it’s about the *size* of the resources, which wouldn’t change even with a resource-merging plugin.

Browser caching wouldn’t help much in my situation, either, because most of my site visiters actually don’t visit one of my gallery pages at all. I have a number of gallery pages in a particular section of my site, where I want to use PhotoSwipe, but many of my visitors just go to the home page and maybe a few other pages, without visiting any gallery. Therefore I don’t want them to have to download 105 KB of files that they won’t need. That’s my #1 reason for requesting this feature.

I do understand the concern of not wanting to confuse users with a new setting like this. Perhaps this could be avoided by putting it somewhere “out of the way”, eg. in a hidden Advanced section or a new Advanced tab, for example, and with a very clear warning and explanation of what exactly it will do.

I’d even be okay with just having a PHP function that I can add to my functions.php file, which would enable it – therefore it’s only for advanced users who know how to do that – although I still think it’s easier and nicer if it’s included in the GUI as a special advanced setting. ??

What do you think?

Hi Arno,

The reason for my request here is similar to the other request we discussed yesterday regarding minimising CSS and loading JS in the footer: every little thing that can be done to improve page speed and performance, all adds up.

Currently the plugin loads 5 separate files (2 CSS and 3 JS files) on every page of the website, whether they are needed or not. These 5 files have a total size of 105 KB, which is not insignificant – again, bearing in mind many people these days browse the web on mobile phones using slower mobile data connections. And that means the client has to make 5 additional requests or connections to the server to download those files, on pages where they aren’t needed.

It’s also a factor for page scoring sites like GTmetrix or Google’s PageSpeed Insights.

In my experience, most plugins which are only needed on certain pages – for example, forms plugins (eg. WPForms) or gallery plugins (eg. Envira), or any other type of plugin which is only required on certain pages rather than site-wide – these plugins only load their CSS and JS resources on the pages where they are used. I think that’s the recommended “best practice” for plugins.

You also mentioned the scenario where another lightbox is already in use. Well, what if a user had another lightbox that was used on the majority of his pages, and he only needed to use PhotoSwipe on a small handful of pages? That could also be possible, right? Therefore, such a user would also benefit from having PhotoSwipe disabled by default and only enabling it on selected pages.

With all this in mind, I hope you might reconsider to implement this, as a user-selected option? ??

Thank you for considering these two things – I appreciate it! ??

And yes, frohes neues Jahr! Like you, I also live in Germany (although I’m from New Zealand) – but we have an Ausgangsbeschr?nkung here in BW, in addition to the lockdown, so there’s no chance to go out anywhere tonight. ??

Regarding JS scripts in the footer: please excuse me, but I must disagree that WordPress decides itself where to put the scripts when you use wp_enqueue_script(). According to the documentation at https://developer.www.ads-software.com/reference/functions/wp_enqueue_script/ it’s up to the plugin developer to make this decision. There is a parameter called $in_footer which lets you put the script in the footer area. Currently your plugin is not using this parameter, which is why your scripts are going in the <head> section instead.

Google themselves recommend to put JS scripts in the footer if possible. Their PageSpeed tool will flag JS files that are in the <head> section and label them as a “render blocking resource”:
https://web.dev/render-blocking-resources/

The reason is because when JS files are in the <head>, it can slow down the rendering of the page:
https://www.wpbeginner.com/wp-tutorials/how-to-move-javascripts-to-the-bottom-or-footer-in-wordpress/

Therefore many WordPress optimisation guides and articles recommend to load JS files at the end of the page. (Although for me, the most important reason is that Google themselves recommend this). Yes, having a caching plugin is also helpful too, but the point is that to get the absolute fastest page load speeds – and the best score at GTmetrix or PageSpeed – it’s recommended to optimise everything possible, not to simply use a caching tool and nothing else. Every little thing adds up! ?? And caching plugins are not always possible to use, in every situation.

Therefore I hope you might reconsider to use the $in_footer parameter with your plugin?