OnTrack

@sficht ah well, in that case I’ll take your word for it and do that.
Great, even easier!

@sficht – that sounds like a plan, maybe use lib/meta.php 1.9.10 while uploading (large numbers of images but not very often I think) and then revert to 1.9.12 for normal operation?
I’ll compare the two files to see what else changed apart from this function.

I bet there’s a new version to patch this by the I time figure this all out though ??

Cheers for the help, appreciate it.

@markcorder I appreciate the tips. I’m quite happy navigating the WP DB but as you point out, more than a handful a day becomes a PITA.

I’m not so concerned about the ordering of images as the date that’s displayed on the site. I edit the meta in Adobe Lightroom – title, description, date/time (to correct if necessary) etc. I have modified the lightbox display so the caption below each image contains the date, title and description. Took a bit of head scratching to work out it wasn’t my hack or how I was exporting & uploading images that was breaking the date.

PS – I hope v2.0 makes it easier to hack these functions in a child theme. As it is, the only way I have it working is to modify the source of the plugin itself which is far from ideal and goes against all best practice.

Cheers.

Been following this thread for a while now. I don’t want to open my new blog site until this is fixed as the sites main purpose is photo sharing.
I appreciate this is free software, and I really do appreciate the time and effort people put in.
It would be nice to know an update on the time frame though. Are we waiting on new version 2.0? Are we expecting a patch from 1.9.12 to 1.9.13? Are we expecting both?
I haven’t submitted a bug report, do I need to if it’s being worked on?

Curious what everyone else is doing to work around this? Have you gone back to a previous version, if so which one? Have you added your own code? Or are you just manually editing the DB after importing the images?

I did take a look at the function get_date_time() in lib/meta.php and noticed it hasn’t changed for a few versions now, so either it’s not to blame or this bug has been there for more than just v.1.9.12
I’m always interested to see how developers write their code, maybe look to make small amendments, but this lot just cooks my head. I hope Becky is right in that v.2.0 will be tidied up somewhat ??

Cheers.

I’ve just come across this, not only on the Log but for the Redirect lists too.

I have inspected the code and there is no way this could work without additional parameters being passed in the URL. There is PHP code missing.

From what I can see the Log page needs a URL that contains
sub=log (type of list to show)
curpage=1 (to show required page number)
search= (to limit list to search key words)
action2=-1 (not sure)
perpage=50 (how many items to show per page)

If one modifies the URL then the pagination works fine. If one uses the links on the page to navigate the pages then half of the query string is dropped.

It is even worse when showing a paginated list of redirects in a group.
sub=redirects
id=3
search=
perpage=50
These are all dropped from the URL so the page has no way of telling you are asking to display Redirects, what Group they are in, what key word to search for or how many items to display per page.

Again, if one manually types in a URL with all the required parameters the pagination works fine.

I hope this helps the author fix these issues.

Cheers.