Update History

[Nibbler]

Table names are case sensitive on linux. You create the table as update_history_config but drop it as UPDATE_HISTORY_CONFIG.

[François Keller]

Hey Nibbler

Thank's for pointing this. I'll correct the plugin code asp and test it. 

[AlexL]

Thanks Nibbler for your contribution!
But I must split the error in this case - Error 1 - you have the solution is the uninstall drops fails,
but why the reinstall fails? Why don't the install procedure work? Got this create table an error if table already exists?
Why don't this procedure tolerate this? I think the solution is to check if exist the table in the install procedure and to empty it or better to delete it - because of different fields on diferent versions of update history

[Nibbler]

The table creation is fine, it uses CREATE TABLE IF NOT EXISTS. The INSERTs from basic.sql will fail however because the table is already populated. Use INSERT IGNORE to avoid this.

[AlexL]

The Update History shows on my website the history from last 200 days = 23 rows
If I take only the last 4 days = 2 rows - it's ok
But It shows

06 August 2007 : 32 Neue Dateien hinzugefügt zum Album 3.12.2006 Zwickau
06 August 2007 : 52 Neue Dateien hinzugefügt zum Album 3.12.2006 Zwickau

That's not correct - all 23 rows show the date 06 August 2007.

Weirdly because I know that this was shown correct different days in the past.

The things I have changed: I tested the Backup PlugIn V2.2 - for this reason I've deinstalled and reinstalled the Update History repeatedly (with deleting db-table per phpmyadmin) and also used your KeywordsAdd PlugIn. And I've updated to Coppermine 1.4.12 on 1.8.2007

The first I've see this error is after Update to 1.4.12, but I've think then it's from Update - because the Update.php has write to db. Therefore I think all dates was reseted to 1.8.2007 - but yesterday I upload new photos and after this the all date is 6.8.2007 - but I don't touch the other photos at this day.

Maybe the db fields changed between 1.4.10 and 1.4.12?
But the selection 4 or 200 days works correctly only the date that's displays is wrong.

[AlexL]

For everybody who has the same problem with deinstall and install without drop the correct table - please feel free to use my corrected codebase.php - all thanks for the tip to Nibbler

it's not the solution for the other little errors

at the thread from CAPTCHA PlugIn I read about an update to 1.8 - at the change list:

fixes:
=====
- Compatible with 1.4.12's new plugin api

Maybe your PlugIns need an update to? Maybe this is the reason for my new error with the Update-history-PlugIn date that's wrong shown?

[François Keller]

Maybe your PlugIns need an update to? Maybe this is the reason for my new error with the Update-history-PlugIn date that's wrong shown?

Possible, but on this moment, i don't know what to update. I must look the difference between two versions of the captcha plugin...

[AlexL]

Maybe you ask Sami or another from the devs

[Sami]

@Frantz : There was a plugin API change/fix for CPG 1.4.12 , I'm not sure if it's applied to your plugin or not
BTW the fix is, $thisplugin is always copied by reference from now on

also I'm not sure if you could see this thread (dev only board) but it's the one that describe the fix by Donnoman
http://forum.coppermine-gallery.net/index.php?topic=40215.0

I'll check your codebase.php when ever I could

[Joachim Müller]

As Sami suggested, the thread is dev-only. I'm quoting the relevant posting here FYI:

I Fixed (I hope) a situation in the plugin api that caused bizarre plugin behavior when plugins called underlying plugin api hooks.

Typical results were some plugins running multiple times per hook call, and some not running at all.

Changing the ordering of the plugins could alleviate the problem.

The two plugins that I definately found a problem with is minicms and cpgmark.

If cpgmark was second in the list, minicms content began being added twice, and some cpgmark actions weren't being run.

When I reversed the order minicms stopped duplicating its output, though cpgmark still didn't seem to operate completely.

I tracked it down to a situation where cpgmark was causing hooks to be executed while it's own code was executing. Thus $thisplugin was being moved around under it's nose.

The crux of the problem I found is this (summarized):

Code Select Expand


                // Reference current plugin to local scope
                $thisplugin = $CPG_PLUGINS[$plugin_id];  //PHP4 makes a copy, PHP5 would make a reference.

                if (function_exists($plugin_function)) {
                    // Pass the value to the filter's function and get a value back
                    $value = call_user_func($plugin_function,$value);

                    // if the user function calls a plugin api hook $thisplugin becomes inconsistent

                    // Copy back to global scope
                    $CPG_PLUGINS[$plugin_id] = $thisplugin;  //copying this inconsistent $thisplugin is whats creating the problem.
                }



To fix the issue I removed the copy back to the global scope and made sure $thisplugin is always copied by reference.

It fixed the issue and I haven't seen any negative effects. The fix has been committed to stable and devel.

[lamama]

Ehm, maybe I've overread something, but is it possible to show the history list on the start page only?

[Fizzolo]

The Update History shows on my website the history from last 200 days = 23 rows
If I take only the last 4 days = 2 rows - it's ok
But It shows That's not correct - all 23 rows show the date 06 August 2007.

Weirdly because I know that this was shown correct different days in the past.

The things I have changed: I tested the Backup PlugIn V2.2 - for this reason I've deinstalled and reinstalled the Update History repeatedly (with deleting db-table per phpmyadmin) and also used your KeywordsAdd PlugIn. And I've updated to Coppermine 1.4.12 on 1.8.2007

The first I've see this error is after Update to 1.4.12, but I've think then it's from Update - because the Update.php has write to db. Therefore I think all dates was reseted to 1.8.2007 - but yesterday I upload new photos and after this the all date is 6.8.2007 - but I don't touch the other photos at this day.

Maybe the db fields changed between 1.4.10 and 1.4.12?
But the selection 4 or 200 days works correctly only the date that's displays is wrong.

Same problem..i think about the 1.4.12 update.
But with another bug. Not only the date is always the same, but the link at the album is missing the number...
Like this: ".../thumbnails.php?album=". The album names are ok, only the links are wrong.
WHILE the first album, inserted today at the date displayed, have the correct link!
I think the two bugs are connected: resolving the first one, automatically the second too.
Any ideas for this great plugin??
I tried to fix modifying plugin_api.php from

Code Select Expand

// Copy back to global scope
//$CPG_PLUGINS[$plugin_id] = $thisplugin;
to

Code Select Expand

// Copy back to global scope
$CPG_PLUGINS[$plugin_id] = $thisplugin;
as Sami quoted.
But no changes at all 

[AlexL]

In the codebase.php I have found the $date calculation with the $i I can go through the array and found 28.8.2007 and as the next 24.8.2007 - this was the correct days of upload
but I don't understand how the $i is used to increment the output - I hope another has more understanding for this code ...

Code Select Expand


$day = localised_date($row['ctime'],$plugin_update_history_date_fmt);
//$day = ($day, $lastup_date_fmt);
$counter[$day][$row[album_title]] += 1;
$info[$day][$row[album_title]] = $row;
$users[$day][$row[album_title]][] = $row['owner'];
}
$end = $start;
}

$i = 0;
$test = array_keys($counter);

foreach ($counter as $day) {
foreach ($day as $album => $number) {
$date = $test[$i];
$album_info = $info[$date][$album];
if ($number == 1) {
                echo '<tr><td class="tableb">' .$date. ": $number". $lang_plugin_update_history['new']."<a href=\"thumbnails.php?album={$album_info['aid']}\">$album</a>";
} else {
                echo '<tr><td class="tableb">' .$date. ": $number". $lang_plugin_update_history['news']."<a href=\"thumbnails.php?album={$album_info['aid']}\">$album</a>" ;
}
$links = array();

foreach ($users[$date][$album] as $u) {
if ($uploader_name==1){ //show the uploader name if $uploader_name set to 1
if ($u > 0) $links[] = $lang_plugin_update_history['by']."<a href=\"profile.php?uid=$u\">". get_username($u) ."</a>";
}
}
}
$out = array_unique($links);
echo implode(', ',$out);
echo "</td></tr>";
}
$i++;
}else{
//otheerway Show n last uploaded files according settings

[AlexL]

I dont want to disturb, but with this error (all upload days shows the same day) I find this plugIn is not more useful. Has nobody an idea?
If a coder need me as tester - feel free to PM me.

[François Keller]

@AlexL
I've looking in the code (after replicating the problem on my local install). I d'ont see why it happends.
Oddly, the dates are correct while using the archive option  :-\
I'll continue to search a solution (but that does not seem to be in bond with the changes of version)...

[AlexL]

to be in bond with the changes of version

Have you tested with a clean 1.4.10 and a clean 1.4.12?
The update are the one I have made on 1.8.2007 - before all displays from UpdateHistory are ok - after it the problem occur. I don't change the UpdateHistoryVersion at this time.

from changelog 1.4.10-1.4.12

2007-01-14 [Bugfix] Fixed situation in plugin api that caused bizarre plugin behavior when plugins called underlying plugin api hooks {Donnoman}
2006-11-12 [Bugfix] Fixed plugin api sleep and wake actions to be scoped correctly. {Donnoman}

Maybe Donnoman has an idea...?

[François Keller]

Have you tested with a clean 1.4.10 and a clean 1.4.12?

No, only with 1.4.12

[dke]

i have a bug to report:

everything seems to be working just fine on my 1.4.14 gallery, however only the LATEST update "hotlink" does work.

Lets say for instance i add files to album "landscapes" the history will update that ive added picture to "landscapes" and create a link to that album. Then i add pictures to "Flowers" the script does the same thing by adding the line that i added pictures to "flowers" now however the link to "landscapes" is faulty.

The only thing that's different in the link is that the album number of the second and beyond history link is removed, just like this:

http://mygallery.com/thumbnails?=124       <-- correct link
http://mygallery.com/thumbnails?=           <-- all other links past the latest one.

I love this mod but could anyone help me solve this issue please? Link to gallery if requested, its nsfw..

EDIT:

This issue was only with the beta 2.0.1 version, the older versions i didn't get any trouble with! Awesome mod guys!

[dolomites]

Hello,

I'd like to view the updates table on  an external php page, only the table without gallery; how can I do?
Thank'you!

[AlexL]

have a bug to report:

everything seems to be working just fine on my 1.4.14 gallery, however only the LATEST update "hotlink" does work.

The same problem on my site (it is still 1.4.12 - I have to update I know - but no time at this time :'()