Celluloid

artstyle, when you open a thread, please refrain from posting again about the same subject in another thread *without* pointing an url to it, especially if there is already a reply : http://www.oscommerce.com/forums/index.php?s=&...t&p=1241379 Cheers.

Minor problems : 1) Extra commas are present in header_tags_seo.php on lines : l.498 l.500 l.510 l.518 l.526 l.571 l.575 l.579 l.639 l.643 l.647 l.651 For instance l.498 : => Search for [", ] and replace by [" ] on the lines listed (it's usually behind a [name=<something&gt] ( [name="view_result",] for instance ). If it's any use to anybody, I would make a diff-patch file available (otherwise, I would spare me the trouble) 2) input type="input" used instead of input type="text" in header_tags_seo.php on lines : l.510 l.514 l.518 l.526 l.571 l.575 l.579 l.639 l.643 l.647 l.651 For instance l.510 : => Search for [input type=input] and replace by [input type=text] on the lines listed. Mild problems : the one mentionned in my messages above about the endless loop in header_tags_seo.php, but I let you double-check the idea and solution proposed (I admit I don't understand - yet - why the problem would not popup on some installs ...).

I would say you need to either get a transliteration module to convert your greek characters into ASCII-US, I don't think Ultimate SEO is aware of any "alphabet" beyond the ISO-latin family. For instance, that would "translate" : Γειά (hello) to "guelo" or "helo" (I don't know how is pronounced "Γ" in Greek). See http://en.wikipedia.org/wiki/Transliterati..._Latin_Alphabet I know there is a good transliteration module available for Drupal 5.x, you might be able to adapt it for Ultimate SEO. The other solution is to hack in the Ultimate SEO contrib and force it to output pure unicode urls (that is removing any extra conversion from UTF-8 to ASCII-US or ISO-Latin-1) but browsers support may vary and your hosting services need to be able to handle them, too.

Ok, cornered it. 1) function GetKey($fileList, $file) returns either a string value ( if $file equals to the text description of the first 3 items of $fileList ), which means the first 3 select options of the 'new_files' select : SELECT_A_FILE, SHOW_ALL_FILES, ADD_MISSING_PAGES string values. either a numerical value ( if $file equals any text description of a $fileList item beyond the first 3 items ). 2) Without a numerical value in $pageNumb, the " while ($pageNumb < count($newfiles) && ! $failedDupSort) " (l.89) loop is endless. 3) A numerical value is already enforced to $pageNumb if its value is (strictly) equal to the SHOW_ALL_FILES string value (l.86 and l.87) : if ($pageNumb === SHOW_ALL_FILES) $pageNumb = FIRST_PAGE_ENTRY; //skip over the selection options 4) Solution : enforce a numerical value for any other string value in $pageNumb : if ($pageNumb === SHOW_ALL_FILES) $pageNumb = FIRST_PAGE_ENTRY; //skip over the selection options else if ( is_string($pageNumb) ) { $pageNumb = FIRST_PAGE_ENTRY; } => No more endless loop and, for instance, the values entered for the title, description, keywords, etc of index.php and product_info.php are saved in the db. As the same behavior is reproduced latter in the file (l.265 and l.271, for "Get Live Keywords Box Checked") , the strap needs to be put there too. Jack> apart from that, would you like a diff file for the HTML typos on the extra commas and '<input type="input"'> in header_tags_seo.php ? (see several messages above).

Ok, forget this, $_POST['new_files'] can't be an array, it will be the option selected (well its value) from the <select name="new_files" ...>. But what puzzles me is that the loop behavior is bound to this value when one submits the form with the several text inputs title_, desc_, keyword_, logo_ etc (for instance, for index.php : title_3_1, desc_3_1, keyword_3_1, logo_3_1) ... which is always 'Select A File'. Let me get this straight : If $pageNumb is a (string) KEY of the table $newfiles, it doesn't make ANY SENSE in PHP to compare with count($newfiles). And it doesn't make ANY SENSE to treat it like a numerical value and trying to increment / decrement it. What would eventually make sense would be to compare $pageNumb (string) with the last (string) key of the $newfiles array, and (at the end of the while loop) to switch its values with next key in $newfiles (string) keys. Or to store in $pageNumb a numerical value (which is done if $pageNumb is === SHOW_ALL_FILES ).

Well if you could answer my questions below, that would help me understand what the code is supposed to do / what defined values aren't defined :) That would be : + what do the function AddMissingPages and GetFileList are supposed to return ? + what does the function GetKey($fileList, $file) is really supposed to do ? => I've the comment near the function definition : "return the key of the file array for the selected item", but the point is that in header_tags_seo.php the call (not far below the comment " /********************** CHECK THE INPUT **********************/ ": $pageNumb = GetKey($newfiles, $_POST['new_files']); gives the function which seems to be an array ($newfiles) and ... an array ... ($_POST['new_files']) As the compare operator is strict in GetKey ( " if ($fileList[$i]['text'] === $file) " ), that might be the problem ... Another lead I have is that the code in the function AddMissingPages makes suppositions on the lack of rename operations on the Oscommerce base filenames (which CAN be modified an redefined in filenames.php)... Cheers

Jack> could you explain me the logic behind the loop while ($pageNumb < count($newfiles) && ! $failedDupSort) in header_tags_seo.php ? $newfiles seems to be the array behind the input/select new_files, so it looks like one should iterate on this array, BUT there's a problem on my environment (Win 2K, PHP Version 5.2.3, Apache 2.x) with an endless loop somewhere in header_tags_seo.php Here's the result if I try to dump the content of $pageNumb in the loop : string 'Select A File' (length=13) string 'Select A Filf' (length=13) string 'Select A Filg' (length=13) string 'Select A Filh' (length=13) string 'Select A Fili' (length=13) string 'Select A Filj' (length=13) string 'Select A Filk' (length=13) string 'Select A Fill' (length=13) string 'Select A Film' (length=13) [...] string 'Select A Hifh' (length=13) string 'Select A Hifi' (length=13) [...] I would say there is either a problem in the initialization of the variable at those lines : $pageNumb = GetKey($newfiles, $_POST['new_files']); if ($pageNumb === SHOW_ALL_FILES) $pageNumb = FIRST_PAGE_ENTRY; //skip over the selection options or of a problem of a "not strict enough" compare condition in the loop control.

Damn, I'm tired... Of course the max_execution_time is hit at line 103, but that doesn't mean that it's where the vast majority of exec time was spent. Need ... to ... reinstall ... XDebug ... on ... Wamp. Oh dear. I'm too old for this :/

I have the same problem as misillsam , which is, on the Page Controll admin page (header_tags_seo.php), a php max_execution_time timeout ... My categories.php is heavilly modified, but it looks like I followed the steps very carefully (and anyway, what would categories.php have to do with a bug on categories.php ?) ... Any idea why I would timeout on this particular line (103) in header_tags_seo.php ? : $optionID[] = sprintf("option_%d_%d_%d", $z, $pageNumb, $languages[$i]['id']); ( Fatal error: Maximum execution time of 300 seconds exceeded in X:\you\can\not\fight\in\here\this\is\the\war\room\admin\header_tags_seo.php on line 103 ) Please note that I have this problem wether or not I put numerical values in the "sort order" fields. Besides, if I click on the checkbox "View result:" for the index.php page, I'm redirected to header_tags_seo.php without anything seeming to happen. Might it be due to these two typos ? (lines 497 to 500) : <th class="smallText" title="<?php echo $commonPopup['view']; ?>" class="popup" ><?php echo HEADING_TITLE_SEO_VIEW_RESULT; ?> </th> <th title="<?php echo $commonPopup['view']; ?>" class="popup" ><input type="checkbox" name="view_result", value="<?php echo $id_toggle; ?>" onClick="this.form.submit();" <?php echo $checked; ?> ></th> <th class="smallText" title="<?php echo $commonPopup['delete']; ?>" class="popup"><?php echo HEADING_TITLE_SEO_DELETE; ?> </th> <th title="<?php echo $commonPopup['delete']; ?>" class="popup"><input type="checkbox" name="delete_page", value="<?php echo $id_toggle; ?>" onClick="return confirmdelete(this.form, '<?php echo $newfiles[$x]['text']; ?>')" ></th> => Notice the extra comma ( , ) after each ' <input type="checkbox" name="..." ' Firefox/PHP/The leprechaun living in my PC might not appreciate (not tested on IE yet, 'cause I'm lazy). As this kind of typo can be found several other times in the file, this could be a lead ... I'll try to clean all the typos and keep you informed.

You don't need to put it ON ... The previous link you gave DOES give (somehow) the reason why the images don't display ... What would be useful for ANYONE to help you (and not EXCLUSIVELY ME) would be to retrace your steps... That's LIGHT info : you have done all correct from ... ? The official installation procedure ? The hints that were given here and there ? There could be tons of reason why the module doesn't work ... Without any background, no one can help you ...

The link you gave shows an image containing the full URL. I would look for a "echo $_SERVER['PHP_SELF'];" or a "echo $PHP_SELF;" or any kind of "echo /SOMETHING/;" in imagemagic.php an try to comment it ...

Well if the only modifications you did was installing this contribution, there might be, indeed, a problem somewhere : have you followed the installation process carefully and checked errr... what needs to be checked ? (thumbnails generation directory, rights on this directory, etc) PS : I was tempted for a few secondes to answer you by a : " 'Welcome to the official support thread for the " 'Screw Image' Magic " contribution ! - oh damn ! I installed the wrong one ! "

Have you checked this post just above ? : http://www.oscommerce.com/forums/index.php?s=&...st&p=903420

Well, seems like the author is enjoying his summer like every sane people around here... So basically, if someone here DOES bother about losing all the files in the "catalog" directory, here's the patch : In imagemagic.php file, LOOK FOR (inside 'function modify_tn_path($file, $check_cache)') //clean up the cache if settings have changed if (CFG_CACHE_AUTO_CLEAN=="True" && $check_cache) { $cwd=getcwd(); chdir($create_path); foreach (glob("*.*") as $filename) { if (!is_dir($filename) && !strstr($filename,$append_hash)) { unlink($filename); } } chdir($cwd); } AND REPLACE BY //clean up the cache if settings have changed if (CFG_CACHE_AUTO_CLEAN=="True" && $check_cache) { $cwd=getcwd(); /* Just be SURE the chdir worked and that you are not STILL in the /catalog/ directory ... or the glob(*.*) will list your index.php file, your product_info.php file, etc and ... you will "unlink" (ie: DELETE) them : 'Woopsie Daisy !!'. */ if (chdir($create_path)) { foreach (glob("*.*") as $filename) { if (!is_dir($filename) && !strstr($filename,$append_hash)) { unlink($filename); } } chdir($cwd); } } Have fun.

Had you clicked yourself on the link and you would have had your answer :) That's basic - basic - basic stuff in PHP : You have a error linked to the context of execution in your script => error ouput message written to the client (that is, your browser) Hence, you can't send any more headers. A header in the context of an HTTP request is a message the server sends to the user (or the user sends to the server) to inform him : + of the last time the file he requested was modified + of the file-type about to be sent + of the location to redirect the request. + ... many more PRIOR to sending any "real" output (things that are displayed in the browser or can be saved to a file or ... whatever). In the case of the ImageMagic contribution, they are many headers that could be sent, depending if you activated "browser-side cache", "server-side cache", etc ... But your image is not broken due to these headers missing. It's broken because of the initial errors and the following errors of the "headers couldn't be sent". Look here : Warning: Cannot modify header information - headers already sent by (output started at /home/content/s/s/f/ssforza/html/imagemagic.php:21) in /home/content/s/s/f/ssforza/html/imagemagic.php on line 181 ????JFIF?? See the JFIF amongst the weird characters ? It's the beginning of your image. So, get rid of your first error, you'll get rid of the subsequent headers errors, and you'll see the images. => The script can't make it to a directory, likely because it doesn't exists. So, either DIR_FS_CATALOG is not set in your includes/configure.php, either it's set to a wrong value. I would say it needs to be set to the value of "/home/content/s/s/f/ssforza/html/". It it's already set to this value, you have a serious problem :D Cheers.

Ok, here's the second problem I noticed about this contribution, and this one is serious. If you use the caching functionality of the contribution, DO NOT EVER DELETE THE WHOLE TREE STRUCTURE UNDER your thumbnail cache directory. I SAID : DO NOT EVER. Explanation : I don't know the reason, if it's the << glob("*.*") >> call or something else (well, actually, I do have leads), BUT if you delete the whole tree structure under say YOUR_CATALOG_DIRECTORY/thumbnails/ (/thumnails/image/dvd/[...] etc for ) WHILE someone requests a thumbnail from the online website, AT LEAST ALL THE FILES in YOUR_CATALOG_DIRECTORY WILL BE DELETED. And I'm not joking. So basically : 1) WRITE PROTECT all your files at the base of your OsCommerce installation (those in the /catalog directory) if your thumbnails directory is right below it (ex: /catalog/thumbnails) Perform same protection at the right place if the location of your thumbnails directory is somewhere else. 2) DO NOT EVER perform a MASSIVE DELETE of the tree structure under your thumbnails directory, be it by a shell command (rm -Rf) or a FTP connection => if there is THE SLIGHTEST CHANCE that someone's browsing your website and ALL your site files are not WRITE PROTECTED, YOU WILL LOSE SOME. => if you have SSH access, once located INSIDE the thumbnails directory, a "find . -type f -name "*" -exec rm {} \;" MIGHT be safer (*) 3) If you really like taking risks, perform a SAFE backup of all the files on your website (prefered method : rsync via SSH) BEFORE. 4) If anyone has already encounter such problem, drop a message here. The creator of the mod is welcomed to contribute too ... May'be there's a way to restrict the glob function call (to image-type files ...) or perform double checks, I don't know, the way I see it, It's due to the fact that chdir($create_path); might fail awfully at some point (and we don't know it ...), and hence, the "unlink" calls are performed on the BAD files (that is, files ABOVE the thumbnail cache directory structure). I think the script should literally bail out on ANY filesystem related error. A broken image on the website is less dramatic than losing php files ... (INCLUDING your index.php) You've been warned :) (*) I REALLY think the problem is due to the "loss" of the tree structure (ie: the sub-directories in your thumbnails directory) rather than the "loss" of the files

Notice and warning are just that ... notices and warning. The last two you pasted are a simple case of "variable not initiliazed" : PHP is not very strict about variables. There is not required prior "declaration" (as in C, JAVA, ...) of a variable before its use... Back in PHP3, there wasn't event the need to set a value to a variable to use it. BUT if a variable is used in a test condition and has not been set a value before, PHP will issue a notice and create a "blank" variable (whose value will be "" / 0 / false ). That, is, a "recent" PHP, like yours (PHP5) : the tolerance about the use of unitiliazed variables have greatly changed from PHP3 to PHP4, and from PHP4 to PHP5. To answer your question precisely, the notice about "thumbnail_size" is caused by the (line 60 ... to 70, or something ) switch($thumbnail_size) { .... } which is placed after a series of tests to give thumbnail_size a value : // Get the type of thumbnail we are dealing with if ( $_GET['w']== SMALL_IMAGE_WIDTH || $_GET['h'] == SMALL_IMAGE_HEIGHT) $thumbnail_size=1; elseif ($_GET['w'] == HEADING_IMAGE_WIDTH || $_GET['h'] == HEADING_IMAGE_HEIGHT) $thumbnail_size=2; elseif ($_GET['w'] == SUBCATEGORY_IMAGE_WIDTH || $_GET['h'] == SUBCATEGORY_IMAGE_HEIGHT) $thumbnail_size=3; if ($_GET['page'] == "prod_info") { $thumbnail_size=4; $page_prefix = $page ."prod_info_"; } if ($_GET['page'] == "popup") { $thumbnail_size=5; $page_prefix = $page ."prod_info_"; } ==> there MIGHT be special cases when the none of the five conditions are met, hence, $thumbnail_size won't have a value yet. As "$thumbnail_size" is only used for the "switch ... case", you can if you wish, add a $thumnail_size = 0; before the series of if(...). Hence, even if no condition is met, it will have a value (without any consequence for the rest of the script). Same idea about "page_prefix"... But if you don't feel confident, don't try to eliminate the sources of the notice and warning. The very fact you asked this question means you might not have yet the required level of understanding need to "correct" sources for warning and notices ...

Ok, I just drop a message here to warn everyone about two facts, here the first one... The base64 encoding used when enciphering the image path should be change with a "URL safe" base64 encoding ! Otherwise, it will make you crazy if you also use mod_rewrite to build path like /fakeimgdirectory/img-ENCRYPTEDPATH-w-WIDTH-h-HEIGHT-p-PAGENAME => imagemagic.php?img=ENCRYPTEDPATH&w=WIDTH&h=HEIGHT&p=PAGENAME I've lost something like 3 to 4 hours trying to understand why SOME of my images wouldn't show up. The answer is simple : base64_encoded encrypted image path MIGHT contain some special characters like "+", "/" or "=". mod_rewrite MIGHT or MIGHT NOT urldecode the encrypted image path, hence ENCRYPTEDPATH MIGHT contain end up with a "+" character. => The imagemagic.php script WILL shoke on this. Anytime. Solution : quite simple, remplace the calls to base64_encode and base64_decode by calls to these specific functions (source : http://www.php.net/base64_encode ) function urlsafe_b64encode($string) { $data = base64_encode($string); // first, perform a base64_encode, THEN, remplace + by -, / by _, = by . $data = str_replace(array('+','/','='),array('-','_','.'),$data); return $data; } function urlsafe_b64decode($string) { $data = str_replace(array('-','_','.'),array('+','/','='),$string); /* WARNING WARNING - I, Celluloid, commented this. Because I absolutely don't know what it does. But may'be you should reconsider, see the original in the comments on this page .... => http://www.php.net/base64_encode */ /* $mod4 = strlen($data) % 4; if ($mod4) { $data .= substr('====', $mod4); } */ return base64_decode($data); } Modification in html_output.php //Encrypt the image filename if switched on if (CFG_ENCRYPT_FILENAMES == "True" && CFG_ENCRYPTION_KEY !="") { $result = ''; $key=CFG_ENCRYPTION_KEY; for($i=0; $i<strlen($src); $i++) { $char = substr($src, $i, 1); $keychar = substr($key, ($i % strlen($key))-1, 1); $char = chr(ord($char)+ord($keychar)); $result.=$char; } // ORIGINAL : $src=urlencode(base64_encode($result)); $src=urlsafe_b64encode($result); } You will have noticed that I didn't urlencode the urlsafe_b64encoded $result ... Why ? (Source Wikipedia) about base64 encoding : So, basically, ANY character string will end up like a character string composed of [A-Z], [a-z], "+", "/" and "=". "+", "/" and "=" WERE the need for the urlencode. Since we replace them with "-", "_" and ".", which are "URL safe" there is no need any more of a urlencode... Second modification (you might have figured it out by yourself) lies in imagemagic.php : //Decrypt the image filename if switched on if (CFG_ENCRYPT_FILENAMES == "True" && CFG_ENCRYPTION_KEY !="") { $result = ''; $key=CFG_ENCRYPTION_KEY; // ORIGINAL : $string = base64_decode($_GET['img']); $string = urlsafe_b64decode($_GET['img]); for($i=0; $i<strlen($string); $i++) { $char = substr($string, $i, 1); $keychar = substr($key, ($i % strlen($key))-1, 1); $char = chr(ord($char)-ord($keychar)); $result.=$char; } $_GET['img']= $result; } => we just replace the call to "base64_decode" by a call to "urlsafe_b64decode". !!!!!! Just DON'T bother about performing a urldecode. Whether or not you are using mod_rewrite, a urlencoded GET parameter is ALWAYS already urldecoded prior to "entering" the PHP script which "receives" it. Of course, the two functions will have to be declared somewhere in your PHP files. You can place them above "function tep_image" in html_output.php, and at the start of the file in imagemagic.php ...