marcelstoer

I guess this didn’t work out?

I had to fix it myself by hacking PHP…

Are you suggesting that your plugin should basically handle breadcrumbs correctly on a recent WP installation with standard theme? I was looking at your demo but since you don’t have the same constellation I can’t tell.

Based on my own tests and your PHP code I’m now a bit familiar with I conclude it doesn’t work. Besides my real-life test with the gallery template I also tested with a regular WP page ‘X’ to which I added the gallery short code. In that case too the page ‘X’ was removed from the breadcrumb once I navigated to the gallery.

Analyzing the bread crumb PHP code made me realize that all I need is a way to make the gallery overview (gallery-template.php) the parent of any gallery (gallery-single-template.php) in WP.
However, the gallery quick-edit interface in WP only gives me the option to pick a other gallery as parent – but not one of the regular pages. Sure, I can fix that directly in the WP database (wp_posts#post_parent) but next time a gallery is save this is overwritten ??

I guess because the theme only supports breadcrumbs for pages which are in a “regular” menu/navigation. It uses the following PHP code to generate WP breadcrumbs:

<?php if ( function_exists( 'breadcrumb_trail' ) ) : // Check for breadcrumb support. ?>
	<?php breadcrumb_trail(
		array(
			'container'     => 'nav',
			'separator'     => '>',
			'show_browse'   => false,
			'show_on_front' => false,
		)
	); ?>
<?php endif; // End check for breadcrumb support. ?>

However, because the gallery (gallery-single-template.php) opened from the gallery overview page (gallery-template.php) is not in the navigation it won’t show up in the breadcrumb.

Assumptions correct?

No, other than the problem reported here https://support.bestwebsoft.com/entries/37505923-Fancy-box-too-tall-download-link-not-visible- (which may or may not be a bug in the fancybox code) there are no errors.

The old version your plugin uses is just not maintained anymore which is a liability to your plugin (no more bug fixes, no new features, potential future browser incompatibilities, etc.).

I’m really sorry for the trouble but since I don’t want Google to index that about-to-be-released site just yet I stated in the description that you need to add ‘wp/fotos/’ to the base URL.

If set the gallery seems to respect the featured image and use it for the gallery thumbnail.

See here how to set the featured image: https://en.support.wordpress.com/featured-images/#setting-a-featured-image

Sorry cannot edit the original post anymore…

Btw, I just validated that it doesn’t work vice-versa for plugins either. I installed WP in DE then used ‘WordPress Language’ to switch the admin language to EN. Sure enough localized plugins (I tested with CalPress Calendar) show all their texts in DE in the admin interface.

Just include the shim in the head and the script at the end of the body:

https://github.com/mmcc/video.js/blob/da3550a6d83c6b60379e24df06cb805993bbb01a/docs/setup.md

If you’re not using something like Modernizr but still want to include Video.JS before the closing body tag, you can simply add your own shiv. Simply include this in the head of your document:

<script type="text/javascript">
  document.createElement('video');document.createElement('audio');
</script>

Hhmm, if that’s the only reason why aren’t there two scripts then? “Separation of concerns” comes to mind…

Thanks for getting back to me (and thanks for the plugin).

In all the years using WP I never found a good reason why WP should put its scripts at the top by default.

Setting in_footer as false is a change to the default

I guess this should read “in_footer as true…”

It’s also what most plug-ins do (by default).

Yes, it’s all too easy to use the default because in_footer is even optional. Why bother considering the options…
That’s why I contact the authors of all the plugins I use and ask them to reconsider their implementation.

Yes, I had thought about this. Adding an option is…always an option ?? However, I see cases like this always as a good opportunity to find out whether themes follow the WordPress principles or not. I accept that plugin authors have a slightly different take on this.

Ahh.. right, got it. Thanks.

In your opinion is it advisable to have static a title/description in such cases? After all, if it isn’t static it changes with every new post I add to the blog. Not sure if search engines like that.

Hhhmmm, I was a bit irritated by that email:

“To continue on the og: issue, I scanned all the currently approved themes in the directory, out of 1739, only nine contain references to og:* properties:”

and then Rumput Hijau is mentioned. Hence, I thought there must be something wrong with it.

@chip Bennett

If I understand the referenced email correctly, Rumput Hijau violated some of your rules regarding embedded code or the like? What exactly is/was the problem with this theme?