gjanes

Looking at the code, the only way the URL could be a 404 is if the username wasn’t probably populated in the token request URL.

The token itself is stored in different places based on whether you have user or blog level access configured for pe2. If you have user-level access configured, the pe2_username and pe2_token will be stored in the _user_meta table instead of the _options table.

I’m wondering if somehow those settings got goofed up, perhaps in the upgrade or the switch in versions back and forth. If you are indeed using user level configuration for pe2, check the _user_meta table for pe2_* records that would also need to be removed.

There might be a few options:

Caption P Style: white-space: nowrap;
The above would prevent character returns on the caption. But that might blow your table out of whack.

Caption P Style: height: 50px; display: block;
The above (or something similar) would set a static height for all caption elements, making single line captions taller than they need to be, but keeping the height of each cell the same, so there would be no differing heights causing the missing space on the taller ones.

Give those a try and let me know if something works.

I’ll have to investigate this a bit further to determine what the URL might be that’s returning the 404. I’ll get back to you.

Yes, that does sound like you have successfully authorized. However, you might just try revoking access and authorizing it again. Let me know if that makes a difference – as the token URL changed slightly with a correction to a Google bug, so that could possibly have a negative effect on accessing private photos correctly.

I just added caption container class/style settings and caption p tag class/style settings in the latest 2.0.5 version. I’m hoping one of these two options might allow you to do what you need to set a static height.

Also, I resolved this topic because of the related post you have still open:

https://www.ads-software.com/support/topic/thumbnail-captions?replies=8

Looking at that last post, it appears to be related more to the styles than the plugin. What I’m seeing is this:

* Album images styled using “float: left” so they stack nicely next to each other
* An image with a two-line caption consumes more vertical space than an image with a one-line caption
* Because of the differences in object height due to differing caption lengths, the browser floats the next image after a two-line caption in the next available vertical spot – in your example this is the 3rd column because the 2nd column has a two-line caption.

Now, with this problem in mind, I’m not certain how this plugin could be modified to solve this issue. The “class” and “style” options in the preferences are intended to help assist with any tweaking you need to make, so in your example you might be able to set a static height for the caption box.

If an additional class/style option needs to be added specifically for captions, I could probably do that, and from there you could possibly set a static height for every caption box. Let me know your thoughts.

If you have not authenticated to Google, you will only see “public” photos in the dialog. If any of your photos are not public, the only way you will be able to see them is if you authenticate the plugin and get an access token.

This should be resolved in the latest version 2.0.3 which was just released.

This should be resolved in the latest version 2.0.3 which was just released. I’ll close this thread unless other problems arise.

This bug should be corrected in version 2.0.3 which is now available. Please test and let me know.

I’m guessing what has happened is that there’s some additional padding around the images when using the album. You may be able to target that with your theme’s stylesheet.

Or, if it is caused by CSS in the plugin, then perhaps there is something I can change. I’m open to adding an option to remove problematic CSS or to add CSS like what you’ve added above. Let me know if you’re able to determine exactly what is causing the extra padding.

I believe I have found the source of the problem. I have the option in PHP set to allow the short open tags “<?”, and in a few lines of the new version 2.0 code I used <? instead of <?php.

I will be releasing a version 2.0.3 very soon that should solve this problem.

Could you please provide me the album shortcode that you’re using? I will see if I can replicate the issue on my side.

I took a quick look at the HTML and I’m not seeing anything that would specifically cause a break, so there must be some HTML that was introduced that adds a bit of additional padding.

Try this – temporarily reduce the thumbnail size by 10 or 15 pixels. If this results in a fix, then there may be a style applied to the main div or individual div elements that is causing extra padding and forcing the extra wrap.

Let me know what you find.

I believe this may have been resolved in a different thread.