gjanes

From the comments in that article you shared, it appears as though the “wpgallery” tinymce plugin performs such a task, and basically it appears to:

1) before displaying the content in the visual editor, it calls a JS function that processes content to switch the [gallery ...] shortcode into the HTML img tags, etc.
2) before saving the content on an “update”, it calls a JS function that processes the editor content and returns the HTML back to the shortcode format.

So the real problem with that is the time it would take to do step #2. I could use ajax to have wordpress handle #1 fairly easily I would think. But reversing #1 back to shortcodes for #2 would be the tricky part.

It’s actually a shame that there isn’t a plugin for wordpress that does this already, since this type of operation would be generic for any and all wordpress shortcodes.

Don’t know that such a thing would be feasible for this plugin alone given the amount of time I allocate to development on it.

This is an interesting concept, and I could see the benefit. Although looking at the example code provided in that artcile, it appears to me that the shortcode isn’t actually being processed by wordpress, but instead the JS plugin for tinymce is processessing it.

Now, I already have some functionality in place to use an ajax request to process the shortcode and return it (for the option to return HTML instead of shortcode), so I could probably utilize that in a tinymce plugin of some kind.

But again it may be a matter of how much time it would take to implement, and also if it would have the desired outcome. I would be afraid that if I parsed the shortcode for the tinymce view, that if you did an update it would actually replace the shortcode in the post with the HTML… I’m not certain I know exactly how this would work, or how the built-in [caption] processing for tinymce works, as mentioned in that article.

Anyone else have any experience doing something like this?

Yeah, I looked at several phototile layout projects, but nothing really seemed to imitate Google+ very well.

I also looked at several of the box packing problem algorithms and libraries available, but again nothing really fit what I wanted to do in matching what Google+ does.

So, I finally wrote my own. And the mechanism is simple enough, except for the scaling and rounding issue, which I tried several iterations of changes to perfect and never could quite get it perfect.

I would love for someone with some extra time to review my code and provide suggested enhancements, but I’ve already probably allocated too many hours to it myself.

I wrote the phototile layout myself. There wasn’t any 3rd party library that seemed to accomplish what I wanted it to do in replicating what Google+ does.

The photos are actually being cropped in the phototile layout, but the problem is determining the exact width (minus the borders) to make each photo, especially when in a series of 4 photos in a multi-row layout, 4 of the same width don’t add up to the target width, so the photos need to differ in width, some rounding up and some rounding down.

I’m sure that there would be a better way to handle the dimension setting, but I had spent enough time on the functionality that I didn’t want to commit any further time – it was “good enough”.

I would gladly accept suggestions for improvement from anyone who wants to pour through the code, make changes, test them and then provide me with the modifications to make.

I’m assuming what you’re requesting is an option to limit the number of albums displayed in the dialog to a specific number, but then allow paging to additional, older albums?

The original intent of the plugin was to display the most recent X number of albums (where X is configured in the options), since the vast majority of people who use this plugin are accessing recent albums to post in a blog.

If I find that more people would find it beneficial to be able to access older albums while still using the album limiter, I can consider adding paging functionality as a feature to a future release. But I’d want to make sure there was enough interest to invest the time in the development.

The problem is the fact that the phototile display must round when scaling to the dimensions that you request.

For example, the actual dimensions where the phototile will display without rounding would be 1000 pixels in width. Even divisors of that also work *fairly* well, but again when it has to scale to your width, then scale all photos to match, a photo must be requested in even pixel amounts, but the scaling usually ends up with decimals.

The plugin does the best to figure out the best way to round either up or down to make things add up correctly, but unfortunately it never quite works perfectly.

If someone wants to look at the code and offer suggestions for better ways to handle rounding and image dimensioning, I’d be happy to implement it. But the logic got really tricky and I got tired of fighting with it and got it to a “close enough” state and let it go.

The private access requirement is a requirement by Google (I have no idea why), I have the same argument that if my albums are public, tag searching shouldn’t require private access. But, Google does as Google does.

I’m not entirely certain I understand your situation, but the unexpected filtering results may also be due to a tag searching bug in google+. There’s an FAQ entry that describes the problem, but basically tag searches are not working properly on Google’s side, even though this plugin requests the tag search correctly.

Read the FAQ and see if the tag searching problem sounds like the issue you’re having – it may be completely unrelated to the private photo access.

I have been meaning to review the options for the plugin and figure out a way to simplify everything without reducing functionality and flexibility for all of the vast uses this plugin is used for.

Hopefully in a not-to-far-off major-version release of the plugin I will have the options greatly simplified. Keep your eye out.

Any follow-up on this? I’d like to help, but I need you to provide additional information.

Hmm, yes – the “Single image thumbnail size” is designed to be proportional. I’ll see if I can figure out a way to allow sending both dimensions. I know its possible, its just making the plugin interface smart enough to support it.

I think all you need to do is sign out of Google prior to requesting private access on the blog.

When the private access request is made to Google and you’re signed out, it will prompt you to sign in. At that point you can sign in with the correct Google account where your photos are stored and grant the blog access.

There is an option to turn that off. Simply set the option.

I will add a FAQ entry for this plugin that mentions disabling the CKEditor for WP plugin may correct this issue.

Is anyone who has seen this problem previously with this plugin able to test this plugin’s latest version to see if the changes I made make any difference to the issue?

Paul – if your theme includes the wp_head() function call (which you showed me it did), then this plugin will include all of the libraries that it needs, and that function will add them to your site.

So the problem is not that the required libraries are not there, the problem is that the theme you’re using is somehow conflicting with them. Or, and perhaps more likely, your theme is throwing some sort of JavaScript error prior to the photoswipe logic running, which would prevent any of the photoswipe logic from executing.

Like Jan said, you’ll probably need to either contact the theme developers and report the problem, or select a different theme.