DZ

@dzaikos: You keep replying in multiple threads with this same point about the classic editor plugin, but the developers have this backwards. Gutenberg should be the plugin, the classic editor should be in the core. [source]

@anevins: @dzaikos, That’s the way it is and we’re just asking for why people don’t feel like it should be that way. This should not be a criticism on @karmatosed. If you have anything more to add to your review please add it there instead of posting on other people’s reviews. [source]

So much for community. Sometimes we can support other reviews but sometimes we cannot?

Anyway, I don’t see how I’m criticizing @karmatosed; I’m drawing attention to the position held by said individual through their consistent responses: 1, 2, 3 (and more but I didn’t feel like going through more threads). This was done to lead into my point that I hold a different position. It’s a constructive argument, but I get the impression it’s not welcome.

So be it. The stars at the top of the forum speak for themselves.

Yeah, but Gutenberg’s “code” editor is not really the same thing and the classic editor plugin doesn’t include the plain HTML box like the core does now.

Gutenberg, in my opinion, sucks. Especially on iPad where I do most of my writing (it’s pretty much unusable with typed text appearing below the viewport and the screen constantly jumping around). If I can’t have a simple textarea then I’d have to write my own editor and I simply don’t want to put that much work into something that should otherwise be frictionless.

As of version 3.5 all HTTP requests now use SSL.

Relative schemes should be avoided. If a site supports SSL, SSL should be used. And Bible Gateway does support it.

As I’ve mentioned in previous posts here, I’m not too motivated to continue maintenance on this plugin as I’ve stopped using WordPress awhile ago. However, I’ll consider making this change if/when I update the plugin for the next WordPress release.

Thanks for bringing the issue to my attention.

Well, to be honest I’m really considering end-of-life’ing this plugin. I moved away from WordPress quite some time ago.

Nevertheless, what you want is doable if you’re willing to do a bit of PHP coding. The dz_biblegateway_votd_admin::remote_get_json_helper() method applies a filter with the compiled HTML, but it also passes the raw JSON data. You could write a function (perhaps store it in your theme’s functions.php file). The function would take the raw JSON data and build its own HTML; the plugin would use that.

You could even copy most of the code from remote_get_json_helper() and just add the appropriate div tags (though, semantically, a span tag is more appropriate).

Looks like everything is working now. I’m going to mark this as resolved. Feel free to post again if you have any issues, etc.

Update the sidebar to use the VOTD widget. Let me know when you’ve done that and I’ll take a look at the source code to see what’s going on.

Regarding the page (/votd/). It appears to be working just fine there. I see the verse loading, which at the time of my posting this is Prov. 1:8-9.

Regarding the widget (/tuis/). You’re doing it wrong. You don’t use a text widget with the shortcode (you actually can but WordPress doesn’t parse text widgets for shortcodes by default; you have to enable it programmatically). Instead, use the actual verse-of-the-day widget. If the shortcode is working, the verse of the day widget should be listed as an available widget. Just drag it over to the appropriate sidebar. You can customize the title and translation.

Let me know how that works.

No errors? No website URLs? It’s going to be difficult for me to help.

Try viewing the HTML source code to see if there are HTML comments reporting errors.

All text and links are taken directly from Bible Gateway’s site. If the link the plugin is providing is broken, it means Bible Gateway served the wrong URL to the plugin.

The example you provided is probably a typo on their part; however, if they fixed it, the change might not be reflected on your site immediately because, by default, the plugin caches the data for fast performance. There’s an option to clear the cache on the settings page.

You’re welcome.

I honestly can’t tell you about the links basically going to the same place (more or less). I just wrote the plugin to make it easier to embed Bible Gateway’s verse; they actually present it that way and I just replicate it.

As for opening links in new windows, if you put that code in your theme’s file you should be good. It won’t really add any overhead and while I cannot imagine any situation in which it would cause problems you can alway remove it if you find some conflicts.

I’ll keep your suggestions in mind for a future update; maybe I’ll find a way to add it without confusion.

Here’s the problem, if a WordPress admin is using either the jQuery or Basic embed methods, all the rendering is done on the client/visitor browser. While jQuery could manipulate the HTML to force opening links in a new window, the Basic method could not (because that code is literally controlled by Bible Gateway’s service).

In the end, this creates an inconsistent user experience for the WordPress admin. One embed method (Cache) would support forcing new tabs/windows, one (jQuery) might, and one (Basic) definitely would not. I’m pretty sure it would create more support inquiries for me and I don’t want that. ??

You could resolve this by using something like jQuery to intercept all links within the appropriate class (all embed methods wrap the HTML in a class for this type of thing). This would work with all methods but requires JavaScript (shouldn’t be a problem for most users).

Alternatively, the plugin is filterable. If you’re using the Cache embed method you can just add some code to your theme’s functions.php file and it would add it on the server-side. Something like:

add_filter( 'dz_biblegateway_json_parsed', function ( $parsed, $json, $filtered ) {
	$parsed['verse'] = str_replace( '<a href=', '<a target="_blank" href=', $parsed['verse'] );

	return $parsed;
}, 10, 3 );

This won’t take effect until the cache is updated (it can be forced to refresh in settings or will update itself in a day). Note the sample code is very basic. It does the job but be aware that future plugin updates might break this… Though you should generally be okay.

This issue should be resolved with the 3.4 release of the plugin (available May 14, 2015).

Let me know if any other issue occur.

Glad to hear it’s working better now!

Update: I should add that the update doesn’t make the audiolink work or appear, it simply does a better job checking if that particular verse and translation provide audio; if not, it omits the speaker icon/link.

In short: If audio is provided, it shows the speaker link. If audio is not provided, it does not show the link.