Hi,
thanks for your feedback and code change. Undortenly that code does not work for me, because I use symlinks in my dev setup and the full path to my symlinked folder turns upp when I use __FILE__. So no go.. I did however change the plugin location detect function a little bit in the next version, so when it comes out later this weekend please feel free to test it and let me know if there is any difference.
Hi Pär,
I’ve looked over the latest code in Version 1.2. What you’re using to create the url to for the files isn’t working when a system has some of its plugins in a symlinked directory. Your line #45:
$plugin_dir_url = plugin_dir_url(basename($aa)) . basename(dirname(__FILE__)) . '/';
only ends up pointing to the main plugin directory and looking for the files there.
Does this still not work for you?
$plugin_dir_url = plugin_dir_url(__FILE__);
-Scott
Unfortunately it doesn’t. On my system it gives me the path:
http://playground-nightly.ep/wordpress/wp-content/plugins/Users/bonny/Dropbox/Webb/Simple-History-GIT/
While the correct path for me is:
http://playground-nightly.ep/wordpress/wp-content/plugins/Simple-History-GIT/
I’m also using symlinks, and that’s why that doesn’t work. Is it because hard/soft-links? I’m using soft I think..
Hey Pär,
It definitely seems like the setup of your symlinks is causing an issue and requiring an abnormal way to find your plugin file. You should have your plugin file within the WordPress file system.
Is “/Users/bonny/Dropbox/Webb/Simple-History-GIT/” inside of the /wordpress directory or outside of it?
For instance, we have created code to allow us to have two plugin directories. This is similar to how multi site would have it’s own set of plugins. But, both plugin directories reside inside of our docroot on the server.
Therefore, if we are grabbing the link to something in the main (normal) plugin directory, the url comes out as:
http://example.com/site-content/plugins/some-plugin/some-plugin.php
path:
/docroot/site-content/plugins/some-plugin/some-plugin.php
and if we’re grabbing the link to something in the secondary plugin directory, the url comes out as:
http://example.com/weirdpress/weirdpress-plugins/our-plugin/our-plugin.php
path
/docroot/weirdpress/weirdpress-plugins/our-plugin/our-plugin.php
So, you can see that both folders “site-content” and “weirdpress” are on the same level inside the docroot.
Hope that helps,
Scott
Aha! I figured it out.
Did some delving into the code, turns out by choosing to sort by date (Settings->Sorting images in album) we’re making all of the images in these albums the same. It seems that when my Android device (Samsung Galaxy S4) uploads images to to Google Plus, that it uploads them all at the exact same time. So, when we select to sort the images in an album by date, then they all have the same exact date.
So, at line 1718 of picasa-express-2.php is this code:
case 1: $key = strtotime($this->get_item($item,'pubDate',true)); break;
Which then makes the $key the exact same for each image. Thus, when making the $images array,
$images[$key] = array (...)
[array starts at line 1722]
the $key for each image is the same and it therefore wipes out each other image except the last one.
Sadly, it looks like the actual rss feed from Google only has one date, and that’s the pubDate. So, the code for this plugin needs to be re-written to check if the $key made is repeated and if it is, it should create a different $key. Or it could just add the imageTitle to the pubdate key, thus making it unique.
If you want immediate results as a user, just change the sort order of your images on the settings page.
Hope this helps everyone,
Scott
Hey scott, thanks for the answers. Did the second answer go into the wrong forum perhaps? I don’t remember having any settings for images in my plugin 🙂
Ha! That’s hilarious. I was definitely answering about another plugin. Thanks for the heads up.
