Search Album Title & Description - Page 3 Search Album Title & Description - Page 3
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

Search Album Title & Description

Started by Paver, January 15, 2006, 09:43:32 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Nibbler

Works properly with the classic theme. I suspect you have overridden the function that contains the fix with your own function in theme.php. You'll need to apply the fix manually to your theme.

lordprodigy

you are right. I had seen that thread about the ecards, but didnt think would apply here. Thanks a lot. The template problem is solved.

I still get the There was an error while processing a database query error
debug info
While executing query "SELECT *,a.title AS title,a.aid AS aid,a.description as description,p.ctime as ctime FROM cpg132_albums as a LEFT JOIN cpg132_pictures as p ON (a.thumb=p.pid) WHERE (a.title LIKE '%time%' OR a.description LIKE '%time%') AND cpg132_pictures.cpg132_pictures.aid NOT IN (53,95,96,99,113,117,127)  ORDER BY a.pos" on 0

mySQL error: Unknown table 'cpg132_pictures.cpg132_pictures' in where clause

File: /home/b514/public_html/photos/include/functions.inc.php - Line: 248

it only happens if i am not logged in as admin. it works fine in admin mode.

Thanks for all the help!

Nibbler

Comment out this line in codebase and see what happens

$META_ALBUM_SET = str_replace( "aid", $CONFIG['TABLE_PICTURES'].".aid" , $META_ALBUM_SET );

lordprodigy

i get Parse error: parse error, unexpected '<' in /home/b514/public_html/photos/plugins/search_album/codebase.php on line 239

Nibbler

Comment it out using php comments

// this line is commented out

not html comments.

Paver

Well, this is embarrassing ... the $META_ALBUM_SET line Nibbler mentioned I didn't really know what that did when I put it in there - it's the *only* line I didn't understand (really!) - I grabbed it from the 'lastalb' code.  So I'm not surprised if it's useless or does something bad.  I forgot about it until now.

If your problem is the search results with albums with 0 photos, here's a quick fix that will remove the database error and gives a result with the correct link but with bad stats & no thumbnail.

Find this block of code in function searchalbum_hijacklastalb:
$query_newpic = "SELECT *,a.title AS title,a.description as description,p.ctime as ctime FROM {$CONFIG['TABLE_ALBUMS']} as a,{$CONFIG['TABLE_PICTURES']} as p WHERE (a.aid=p.aid AND p.ctime = $maxctime)";
$result_newpic = cpg_db_query($query_newpic);
$rowset_newpic = cpg_db_fetch_rowset($result_newpic);
$rowset[$irow] = $rowset_newpic[0];
mysql_free_result($result_newpic);

and replace it with this block:
if ($maxctime) {
$query_newpic = "SELECT *,a.title AS title,a.description as description,p.ctime as ctime FROM {$CONFIG['TABLE_ALBUMS']} as a,{$CONFIG['TABLE_PICTURES']} as p WHERE (a.aid=p.aid AND p.ctime = $maxctime)";
$result_newpic = cpg_db_query($query_newpic);
$rowset_newpic = cpg_db_fetch_rowset($result_newpic);
$rowset[$irow] = $rowset_newpic[0];
mysql_free_result($result_newpic);
} else {
$cpg_nopic_data = cpg_get_system_thumb('nopic.jpg',10001);
$cpg_nopic_data['filename'] = basename($cpg_nopic_data['thumb']);
$cpg_nopic_data['filepath'] = dirname($cpg_nopic_data['thumb']).'/';
foreach ($cpg_nopic_data as $key => $value) {
$rowset[$irow][$key] = $value;
}
$rowset[$irow]['caption'] = '<img src="' . $cpg_nopic_data['thumb'] . '" ' . $cpg_nopic_data['whole'] . ' class="image" border="0" alt="" />';
// $rowset[$irow]['aid'] = $row['aid'];
// echo "<pre>"; print_r($cpg_nopic_data); echo "</pre>";
// $rowset[$irow]['title'] = $row['title'];
// $rowset[$irow]['description'] = $row['description'];
// $rowset[$irow]['category'] = $row['category'];
}


As you might be able to tell, the new code has some commented out lines which is part of my testing for the correct code that will give the correct system thumbnail for 'nopic' and the correct stats.  I haven't had time to work on this since I last posted.  I figured I'd post this little bit now if you want to remove the database error.

lordprodigy

#46
Hello Nibbler, Paver,

I tried both of the above options but none of them yielded a successful search. :( This is the debug info i get:
debug info removed

In this case, I dont think it is an emty album problem, as I dont have any. The weird thing is that it works well in admin mode...  Any more clues? :( I appreciate your help.

edit: I removed the debug info as its not needed in this case.

Joachim Müller

1) never leave admin mode
2) don't post debug_output unless requested

lordprodigy

I had no choice, since the plugin works only when I am signed in as admin. If I am not logged in, I get the above error.  :(

Paver

#49
I don't understand what the error is now.  If you commented out the $META_ALBUM_SET line properly, you shouldn't have the cp132.pictures.cpg132.pictures error and you shouldn't have the '<' error.  If you have no empty albums, you shouldn't have those errors as well.  What's left?  The debug_info, as GauGau said, is only useful in certain cases and so should not be posted unless requested.  In addition, it doesn't include the error message so I don't know what the current problem is.  I tried 'USER_MODE' right now, and the plugin works fine.

I'll post a quick fix now to remove that $META_ALBUM_SET line and remove the empty album error since it's embarassing to have script-killing errors in a release.  The caption for empty albums will not be correct yet - it's an "issue" until I decide how best to deal with it.

edit: Hold on a second, I think I know what your error is.  And I think I have fixed it.  Just a minute . . .  (well, after lunch)

lordprodigy

Thanks Paver, take your time. Bonne appetit. It doesnt affect the usage of the site (except search)

To state clearly the above errors above are taken care of. I was commenting as Nibbler said with the html commands and not the php... silly. I dont have empty albums, so the empty album problem doesnt affect me. The problem is that, as a normal user any search string gives me the "There was an error while processing a database query" error. While logged in as admin, the plugin works great...   :( take a look at www.b514.com/photos.

Thanks a million.

Paver

Yeah, this is a serious error.  It occurs if you have group-restricted albums so $META_ALBUM_SET has a value (which includes the albums that are restricted from the current user's group).  If you have no restricted albums, you don't see this error.

It's a serious mistake because I should have tested this on various user groups.  The plugin is basically useless until I fix this.  I have a fix that works now, but I want to test it out and tweak things a bit before I release it.

lordprodigy

Paver, I am happy you found the problem. I do have restricted user groups so you are right on the spot. For now I will take out the plugin and will reinstall it when you manage to update it. I will keep an eye on this thread for the new release. If you want me to do some testing on my site let me know.

Thanks a lot!!

Paver

v1.08 has been added to the first post as usual.  It includes 2 important bug fixes, one that killed the script, the other merely unprofessional-looking results.


  • When the user was restricted from certain albums, the search would die because I didn't implement $META_ALBUM_SET correctly.  Now it's fixed.
  • When there were empty albums, the search results would show bad thumbnails and bad stats for these albums.  That fix took some more work because of the way system thumbnails are used.  I may look at improving this in the future.  Regardless, the plugin works as expected now.

lordprodigy

Paver, I tested it and all problems are gone. works as expected. its great. thanks a lot! Its a wonderful plugin! Great work!!!  ;)

Paver

Fiddlesticks.  I need to report 2 known issues with the current version (1.08).  I thought the more serious one (the first one) was due to another plugin, but it looks like it might be this plugin's fault.


  • With the "Search Album" plugin on the bottom in the priority list (of the plugin manager), the empty albums fix works fine.  If the priority of this plugin is moved above any other plugin, the thumbnail disappears and in addition the "Search" link on the system menu (or anyplace else you have it) is not replaced with the plugin search link.  This is due to the plugin's "page_html" filter not being called; I haven't tracked down why this is yet.  The current work-around is to push this plugin to the bottom of the priority list.
  • The album search is apparently case sensitive.  I'd prefer case insensitive, so I'll add that for the next version.

lordprodigy

I came across the Search link problem before but I thought it was fixed in 1.08... (my plugin is last in prority list)

Good point about the case sensitiveness... insensitive is better in my opinion too.

Paver

Are you saying that with the plugin last in the priority list, you still have the search link problem?  Or are you saying you saw the problem before when the plugin was higher up, but now that you've installed 1.08 and it happens to be last, you don't see the problem anymore?

lordprodigy

the second one. Right now the plugin is last and I don't see the problem anymore.

Paver

#59
Ok, that makes sense.  It's a weird problem.  I would think giving a plugin a higher priority would always make things work even if the plugin doesn't "behave".  Only working with a lower priority is weird.  I have tested it with only one other plugin installed - Nibbler's file-type editor - and that plugin doesn't use the "page_html" filter.  I'm glad there's a work-around because this will take some troubleshooting to figure out.  If Nibbler or anyone else has some thoughts on this, please let me know.  It does remind me of a common looping issue where you don't pass the processed value in the loop to the next iteration and so the next iteration uses the original value which causes the final output to appear to only have processed the last iteration.  In this case though the file-type editor plugin doesn't have a "page_html" filter so it's effectively an empty iteration.  Hmm . . .  The only other thing that comes to mind is that the output buffer is flushed in my plugin code somehow and so the output buffer callback function is called prematurely.  I don't have any explicit ob_end_flush() calls though, so it's not obvious if this is a possible cause.  But why would that happen only when another plugin is installed and exists at a higher priority?  Hmm . . .