Velveeta

Try changing that query to this (i've substituted in the actual likely variable names in place of the static text, but you may have to proof it when you stick it in to make sure your products_id var is $products_id, or else change $products_id below to what it actually is in your code, i.e. maybe $rInfo->products_id or something like that): select count(*) as total from " . TABLE_REVIEWS . " r join " . TABLE_REVIEWS_DESCRIPTION . " rd on r.reviews_id = rd.reviews_id and rd.languages_id = '" . (int)$language_id . "' left join " . TABLE_REVIEWS_IMAGES . " ri on r.reviews_id = ri.reviews_id and ri.reviews_status = '1' where r.products_id = '" . (int)$products_id . "' Good luck :) Richard.

Sorry about that, yes, MySQL 5 moves more towards a 2003 standard of query syntax, as a result, this query will need to be subtly modified from: // BOF Review Images $reviews_query = tep_db_query("select r.reviews_id, r.products_id, r.customers_name, r.date_added, r.last_modified, r.reviews_read, rd.reviews_text, r.reviews_rating, ri.reviews_image, ri.reviews_status from " . TABLE_REVIEWS . " r, " . TABLE_REVIEWS_DESCRIPTION . " rd left join " . TABLE_REVIEWS_IMAGES . " ri on r.reviews_id = ri.reviews_id where r.reviews_id = '" . (int)$rID . "' and r.reviews_id = rd.reviews_id"); // EOF Review Images To either this: // BOF Review Images $reviews_query = tep_db_query("select r.reviews_id, r.products_id, r.customers_name, r.date_added, r.last_modified, r.reviews_read, rd.reviews_text, r.reviews_rating, ri.reviews_image, ri.reviews_status from (" . TABLE_REVIEWS . " r, " . TABLE_REVIEWS_DESCRIPTION . " rd) left join " . TABLE_REVIEWS_IMAGES . " ri on r.reviews_id = ri.reviews_id where r.reviews_id = '" . (int)$rID . "' and r.reviews_id = rd.reviews_id"); // EOF Review Images Or this: // BOF Review Images $reviews_query = tep_db_query("select r.reviews_id, r.products_id, r.customers_name, r.date_added, r.last_modified, r.reviews_read, rd.reviews_text, r.reviews_rating, ri.reviews_image, ri.reviews_status from " . TABLE_REVIEWS . " r inner join " . TABLE_REVIEWS_DESCRIPTION . " rd on r.reviews_id = rd.reviews_id left join " . TABLE_REVIEWS_IMAGES . " ri on r.reviews_id = ri.reviews_id where r.reviews_id = '" . (int)$rID . "'"); // EOF Review Images Try one of those and see if it starts working for you :) Richard.

Thanks for the info :) I've tweaked his install of the software to accomodate the fact that he's in the UK and using the Display Prices with Tax option, as that was causing problems at paypal's end w/ the totals not adding up correctly, and everything looked to be working just fine until this problem had popped up, and I couldn't figure out where the hell it was at :D Thanks to that little tidbit above, I found where the problem was and commented it out, so we'll see if that fixes it :)

Does this mean that we can simply put in a hack to have it send the billing address in place of the shipping address when it transmits to paypal, and that should get around the problem?

ok, fixed this on my own... for posterity i'll post it here :D it was indeed retaining the session info but losing the global links to the session data... the reason was because of the message_die() function in the phpBB... php will pass global variables along to other files as long as the files are included or required into the main file... it won't pass them with function calls unless you specifically pass them as a parameter... this code path was routing through a call a message_die(), which in turn proceeded to include its page_tail.php file, which included column_right.php and finished off the page... the fact that it made a function call to message_die, which then ended up closing out the page, is why it lost its global variables, they weren't passed along w/ the function call... my solution was to just find a large grouping of global variables so i wouldn't end up missing any (if you remember, this problem followed the shopping_cart box down to the whats_new box) from the order class in includes/classes/orders.php, which had globals for things like $cart, $currency, etc... and i pasted that line into column_right... that way everything is re-globalized when it hits the column_right include, and if it's already global (not having gone through the forums, say for standard store browsing), it shouldn't hurt anything :D

Hi everyone, I just installed this in my store yesterday, and have nearly gotten all the bugs worked out of the installation that I could find, and gotten it fully integrated into the store display... I thought I had them all, and so went to post the first announcement in the forum, and when I posted it, I got this error: Fatal error: Call to a member function on a non-object in /home/allthing/public_html/includes/boxes/shopping_cart.php on line 23 Now, my shopping_cart box is in column_right, so it comes after the phpbb insert, and appears to be going screwy after that point for some reason... during the browsing of forums and the adding of a new post, i don't get any errors like that, but once i click to post it, i'm getting that error... i tried adding a check to includes/boxes/shopping_cart.php to see if $cart was defined and was an object, and if not, to recreate it the same way that application_top does, but all that did was initialize a new cart w/ 0 items (i had 1 item in the cart for a test), and move on to the new box, which is the whats_new box, where it has the same error, call to a member function on a non-object... Now, i saw a reference to this same error in a post from like June 2004 or something in another thread, and I tried the proposed solution, which was to remove the tep_redirect from the file that was being called when the error occurred (although the tep_redirect in posting.php is only called when authorization failed, so i really didn't want to do that), and it still didn't work, and so now I'm at a loss... I've tried adding some debug info to the output, echo'ing the contents of $_SESSION to the screen... what I see is a correct-looking session array, with a cart variable defined in it, and a product_id listed under it with a quantity of 1... I echoed this at the top of includes/boxes/shopping_cart.php, so as of the beginning of that file, the $_SESSION data was still intact, but for some reason it still said $cart was a non-object, so the only thing I can think of is that cart is defined, but the global variable that references it has been lost somewhere along the line... i could probably patch that, but then, like i said, the problem moves on to the next box, and i really don't want to do a patch job... Does anyone know what's going on and possibly have a fix for this? This is the phpBB contrib for version 2.0.12 by the way, as the 2.0.15 link was broken when i went to grab it yesterday... Thanks in advance :)

if you'd like, i can post my rewritten products_extra_images.php and the language file for it, it's got a working file upload feature, uses the product's name (instead of model) in the left-most dropdown, and also displays the image once it's uploaded... if you don't have a thumbnailer installed, though, that can get a bit bandwidthy when assigning lots of images :D Richard.

ah yes, there was one other thing i forgot to mention... you do need the "new upload" portion in the code... what happens is that the multipart form w/ the file field will automatically upload the file when the page is submitted, but the new upload constructor calls another function that checks the global FILES array, which is where the thing is stored temporarily, and it returns the data that's in that array for the content of the file... at that point you'll also want to make sure you save the file to your images directory... you should be able to get the info you need for these functions by looking at categories.php in your admin directory, and finding the parts where it uploads the initial product image :) Good luck! Richard Lindsey.

if you're still having a problem with this, i had the same problem when rewriting this contribution for another store i was working on... the problem lies not in the upload class, but in the form declaration... when you make your tep_draw_form statement that includes your upload button, make *sure* you do this: Change: <?php echo tep_draw_form('extra_images_' . $extra_images['update_extra_images_id'], FILENAME_PRODUCTS_EXTRA_IMAGES, 'action=update_extra_images'); ?> To: <?php echo tep_draw_form('extra_images_' . $extra_images['update_extra_images_id'], FILENAME_PRODUCTS_EXTRA_IMAGES, 'action=update_extra_images', 'post', 'enctype="multipart/form-data"'); ?> Notice you have to add the 'enctype="multipart/form-data"' to the form declaration... took me forever to hunt that damned bug down, hope it helps :) Richard Lindsey p.s. Long live Chemo!!

Hiya lane, I just posted a little mod this contrib, so I hope it gets rolled into the next version... it just checks for existing sessions before outputting the list of abandoned carts to the admin at the console... this way, they only see carts from expired sessions, instead of possibly seeing carts from people that just happen to still be shopping and not have checked out yet... Really simple, just query for session data and extract the customer_id with a regex, throw it into an array, and implode it in the query to make sure the customer_id isn't in that list of values when outputting the list to the admin... I wrote it on a previous version of this contrib, but grabbed 1.60 before uploading it, to make sure the instructions were compatible with this latest version...

you may want to double-check that you have curl support compiled into php... create a little page called phpinfo.php or something, and put this in it: <?php phpinfo(); ?> then access the page and you'll get a ton of info about your php compile... you're looking for a section at the top that tells what options it's compiled with, and you're looking for this within those options "--with-curl" i believe... then further down the page (just search for curl) you'll find a section dedicated to the curl settings... you should also check to see if over in the right section of that part, you can see OpenSSL as part of the package...

Jack, don't worry about a lack of time, that's what we're here for, so I decided to fix the links for you :D There's now a new version (1.3.2) on the contribution page for this that will replace 3 files, seo_assistant.php in the root admin directory, and the 2 (google/yahoo) php files in the modules directory... these use a different regex for nabbing the url of the target site a little faster, along w/ the http or https prefix, and then save that prefix and crunch the html code down to 1 statement within seo_assistant for displaying the link as http or https, and without the links being within the admin directory tree... If you're already at the latest version, simply grab these 3 files and overwrite your 3 :)

i believe you can force it over to the danish google by going into *catalog*/*admin*/includes/modules/seo_google_position.php, should be line 38 if you haven't edited it at all and are on the most recent version, and change the domain name in $filename to reflect the new google address... i'm not sure which extension is danish, but you would just change www.google.com to www.google.de or www.google.es or whatever, and it should work the same... it would be nice for a future release to see maybe a set of radio buttons in the interface that would allow you to toggle between some of the different googles or something :D

Nice contribution Jack, just a couple of questions regarding it :) I actually just found this thing the day before yesterday and downloaded it, installed it today, and then noticed you'd uploaded a new one today, so i replaced my newly installed one w/ the newest version :D my questions are this: 1) It seems you left out the definition statements for the subheadings in seo_assistant.php, for the values of TEXT_CHECK_LINK, TEXT_LINKPOP, etc... what should these say? Or did I just miss them when I was installing? I checked the english directory to see if it was defined in that seo_assistant, but it wasn't... 2) I noticed you did some work w/ MSN not reporting the link popularity correctly... is there a chance in the future of MSN search getting its own dedicated file and sql tables? I'm guessing with M$'s available funds and market dominance, that their search engine becoming one of the top 3 is not a question of if, but when, so do you plan on giving them the attention that google and yahoo get in this package? Just curious, i could probably write something myself just based on your code for google/yahoo, but since you wrote it originally and are more familiar, you could probably knock it out faster and better than I :D That's it really, thanks for the contrib :)

Does anybody know how I might be able to fix this? Thanks in advance, .:jewelrytrends:. <{POST_SNAPBACK}> Even though you show line 396 as being the line below the actual 'case' statement, that error makes me think that the case statement itself is the problem... check to see if you don't have it after the closing brace for the switch statement it's inside of, like this: switch( whatever ) { case 'blah': break; case 'blahblah': break; case 'blahblahblah': break; } case 'notify': // statements break; perhaps when you were pasting in the code you pasted it outside the switch's closing brace... if that doesn't seem to be the case, maybe try posting us a few lines above and below the line in question :)

ahhh i see what you're trying to do, and in order to do that you'll have to consider a few things first... first, the PRODUCT_NAME that you're looking for is part of chemo's beautifully crafted caching code... what happens is that the db is queries for all categories, products, and manufacturers, and they're all used to construct php code that would insert them into the page as defines, then the entire thing is stored into the cache section of the database... when the page loads, the db then just needs to be queried for that one huge piece of text, and all products, categories, and manufacturers can then be referenced from the definitions that are created, instead of having to query for them all individually... the part of the code that says this: if ( defined('PRODUCT_NAME_'.$p2[1]) ){ $rewrite_page_product = short_name(constant('PRODUCT_NAME_'.$p2[1])) . '-' . PRODUCT_MYFIELD . '-p-' . $p2[1] . '.html'; } else { $seo = false; } break; basically constructs a name to check for, PRODUCT_NAME_1234 (by using the product_id that's stored in $p2[1]) and checks to see if it's defined... if it is, it references that value (the product's name), which is also stored as its own definition for reverse lookup... so basically for each product, this is created... i'll use 1234 for the id, and "blahblahblah" for the product's name :D define('PRODUCT_NAME_1234', 'blahblahblah'); define('blahblahblah', 'products_id=1234'); that way if you know the name or the id, you can look up the other rather quickly without need a db query... if you wanted to add in product attributes as part of the url, and reference them by PRODUCT_MYFIELD, you'd have to create similar entries to be written within either seo_cache.php, or cache.class.php, i can't remember which one, but you should be able to spot the part i'm talking about and copy the format, but you'll have to create one MYFIELD-type field for every type of attribute you want to be able to use in the url, which is another thing to consider, and you'll have to either put something to show what attributes are in it, or else include all attributes in every url, here's an example: http://www.yourstore.com/chrysler-color-red-p-1.html http://www.yourstore.com/chrysler-color-blue-p-1.html http://www.yourstore.com/chrysler-transmis...omatic-p-1.html http://www.yourstore.com/chrysler-transmis...andard-p-1.html the above illustrates how you could put an identifier into the urls to show which define statements should be looked for, below shows the method of putting all attributes into a url so you don't have to identify them... http://www.yourstore.com/chrysler-red-automatic-p-1.html http://www.yourstore.com/chrysler-blue-automatic-p-1.html the problem with this method is that if you have say, 5 different attributes you want to use, and this particular car should only have 3 of them, you'd have to ugly it up a bit by doing something like this: http://www.yourstore.com/chrysler-red-auto...s-none-p-1.html so that when the code parses the url it grabs the right words for the right parameters... so you could construct html_output that would include things like that, and you could write a regex for it similar to this: ^/(.*)-((.*)-(.*)-)?p-(.*).html product_info.php?products_id=$5&$3=$4 that won't do the trick, but it demonstrates what you're looking for, something to capture all the individual elements and them send them along in the translated url for the get process... the other solution would be to send the entire string minus the -p-1 as say, cPath, and let the code parse it into the indivual attributes, which is what i do in my store to accomplish the urls i have... Hope that helps again :D

i just re-read your post and saw you may have questions about other parameters being set in the url, and where they're saved at... in response to this, they're shown in the url just like they would be w/ a regular php call... say you had this normally in php: http://www.yourstore.com/product_info.php?...lor=blue&size=8 then in the rewritten version of the url, it would look like this: http://www.yourstore.com/product_name-p-12...lor=blue&size=8 and the extra parameters would then be tacked onto the end of the new url when mod_rewrite transforms it, so it looks like this when the get request is actually processed: http://www.yourstore.com/product_info.php?...lor=blue&size=8 and google should cache the rewritten version (product_name-p-1234.html?color=blue&size=8) with no problems, which would then translate correctly when they came up in a search engine listing for an end user... i might be off on this last bit of info with how this contribution adds on the extra parameters, but i believe that's right...

it sounds like your host doesn't know too much about mod_rewrite... it's not actually storing static versions of the pages that are being called (which is bad-bad because search engines like changing content), so you won't have to worry about a static page not updating if say, the product's description changes, or you add some new reviews or whatever (if you have reviews showing in the product pages)... here's how it works in a nutshell: osc generates an href link for a product to display on your page using Chemo's rewritten version of the url, for example: <a href="http://www.yourstore.com/product_name-p-1234.html">Product Name</a> the spiders (or users) come through, see the link and click on it, it's then sent to the web server software (Apache, IIS, etc) with a get request for that specific page (and in the case of a spider, it indexes the page address as being that specific address, the rewritten one), and then the request hits mod_rewrite before it's actually processed and returned... mod_rewrite then examines its rewrite rules and any conditions it has for received urls and says "Ok, this url matches this regular expression for ^.*-p-(.*).html" (or whatever the regexes are in this version, i can't remember, but that should match), and then transforms the url based on the matching rule, into something like this: http://www.yourstore.com/index.php?product_id=1234 and actually processes the get request with that info, which returns the correct page and sends it back to the user (or spider)... if the page happens to update with new information the next time the spider comes back, the rewritten url: http://www.yourstore.com/product_name-p-1234.html will still be valid for the page w/ the most current information, as it will be transformed at the server into: http://www.yourstore.com/index.php?product_id=1234 and return the most up-to-date version of that page... when it indexes that link, anyone that brings up that listing in a search engine and clicks on it will have their url transformed at the server as well, and the most up-to-date version of that page will show to them, not some cached actual-.html version of that page... Hope that helps :)

I installed this contribution a few days ago, and of course made a backup of everything, with it being such a large install... It doesn't seem to be working right, and I'm only testing the first of the features I decided to test, which was emailing a Gift Voucher and redeeming it from the email... I haven't even moved past that step yet, to see if everything else is working (though I did have some other problems with something in my shipping module spitting out an error saying i couldn't redefine the cod class when i was trying to checkout)... So anyways, the version of this contribution that i went with was the Feb. 4, 2005 release of it, called "The final" by Kayode Muyibi... well, it had some parse errors in the gv_redeem.php file in the catalog root that I tried to fix, but when i nailed those, and clicked the link from the email i sent myself to redeem a test voucher, the page just loaded blank... at that point, i decided i would paste in one of the newer versions of gv_redeem that was supposed to fix the sql injection that this version was prone to, and even that file had some errors in it, namely the fact that it made the precompiler exit from php mode (?>) and then had sections of code commented in php style that output in the web page, and when i fixed that, it had a parse error that i had to fix... also the layout wasn't correct for lining up the column_right along the right side of the window, it was missing an additional <table> element, and once i got all of that taken care of, now it seems to be reading every test voucher i redeem as $0... Now I'm an awesome debugger when it comes to C, and as such, most of that has transferred directly over to php since they're so similar... but, since this is such a large contribution, and i'm not exactly sure what the interface is supposed to look like when it *is* working properly, it's hard for me to know where to look to debug, and when i read through the gv_redeem.php file itself, it almost looks like it was meant to be part of the installation instructions about where to put different sections of code if you were manually splicing this into your store (every section of code begins with something like: create_account.php, before *this*, add *this*, followed by a code chunk), and it all just got combined into 1 file... it also appears that some of those code chunks are repeated, though i haven't read them in enough detail to determine that they're identical yet... can anyone point me to a stable release of this contribution? I think i'd rather start over w/ the install from my last snapshot and add the various tweaks and bug fixes since that release, than try to debug this when i'm not even sure how it's supposed to behave when it's actually working right... i really would like to have this functionality in my store, however... also, if any of you out there are using this release and/or have had the same kinds of problems i'm having, if you have some light to shed on my situation, i would appreciate it, thanks :)

yeah i would use a js insert to do it, that way the users see it but the spiders don't...

What version of OSC are you running? tep_output_string should be a stock function, at least in MS2 it is i believe (i don't remember adding it to mine at any point)... all it does is format the output text to replace (by default i believe) any special characters (via the htmlspecialchars if i recall correctly) such as quotation marks, apostrophes, ampersands, etc. with their corresponding html syntax: " & etc... i would imagine that if you took out the calls to tep_output_string, those links should still work fine the most part, except when they included one of these characters that should be translated... but those don't specifically have anything to do with the SEO url contribution here, as far as i know, as this contribution didn't implement that function, it came with OSC... perhaps you're running an older version that doesn't have this function? Or perhaps you're not including the proper file to have access to it... it should be in your *catalog*/includes/functions/general.php file... and i believe it's right at the top, like 3rd or 4th function down... Richard Lindsey.

while i'm sure that search engines do rank listings partially based on directory depth, i also know that they rank it based on keywords, and that keywords in the url itself weigh in heavily, and keywords in the domain name itself weigh even more heavily (which is why a lot of people hyphenate their domain names, so they can be parsed by search engines, but search engines are getting better about nonparseable domain names, and no customer wants to type a bunch of hyphens to get to your store :D)... i suppose that if it does end up hurting my rankings, i could simply strip out the parent directories and make it simply www.allthingschildren.com/cribs/index.html, etc... if i learn anything more specific as to the current trends in optimizing for rankings, i'll post em here at OSC in a separate thread :) Richard Lindsey.

i think you misunderstood what i said... if you set a cookie specifically for "www.domain.com", then yes, it is available for www.domain.com/forum/, etc, and not for something like mail.domain.com, because you specified www (although it would be available to some child domain like "mail.www.domain.com")... but if you set a cookie for simple "domain.com" (no preceding dot) and someone elses registers "mydomain.com" and knows to look for a cookie of the name that you've set on the customer's machine, it should be able to access it... by placing a dot at the beginning of the domain name like ".domain.com" you have cut off that type of access because no one could make a fake domain called something like fake.domain.com and hope to access your cookies that way, as the root domain has already been registered... and if you set it equal to ".domain.com" then other child domains of *your* parent domain will be able to access it, if you were to set up a forum.domain.com or catalog.domain.com... it's those domains without the preceding dot that are in danger of this type of hijack, and of course, the domain doing the spoofing of the name would have to also know the name of the cookie you've set on the client... Richard Lindsey.

Thanks for the compliment :D Yes, my urls are a modified version of this contribution... i didn't track my changes as i did it, because it took me a few days and a bit of frustration to get it working right, and get the regexes perfect, and then i actually had to rework all of my regexes because my web host is running apache 1.3, which uses older PCRE translation, and i had to get rid of some of my features *snap*... but it all ended up working, and perhaps one of these days when i either go live or actually have some spare time, i'll take a vanilla version of MS2, slap in chemo's url's, modify em like mine, and use some software that'll snapshot the differences so i repost it to the community... in the meantime i can tell you the gist of what it does... it just uses a regex to find the next word after the domain basename, being product, category, or manufacturer, then goes past the next / to start where it records its data, and records all the way to the /index.html in the case of categories, or all the way to the .html in the case of products and manufacturers... this data is then passed back to the code as the cPath (the entire chain of directories and subdirectories, split by slashes), manufacturer_id, or product_id, and in the code, the product/manufacturer is searched for in the cached table, since it stores data in the same format, and the actual number value is reassigned to that $_GET variable, or in the case of categories, the cPatch is exploded by '/' into an array, the individual elements are searched for in the cached table, the number values are created in another array, and that array is then reimploded with '_' and reassigned to cPath's $_GET variable... hope this is enough to at least get you started :) Richard Lindsey.

oh and chemo, i finally nailed my own problem w/ apostrophes and quotations showing up in my urls after they'd been stripped :D the problem has to do with characters that appear to be apostrophes and quotations but aren't actually represented by the same ascii codes or something... like on some sites where (if this has ever happened to you) they may display some kind of sql tutorial, and you highlight, copy, and paste the text of the statement into your mysql console only to have it crap out on a quotation mark that was used... being a drop shipper (at least initially), i've been pulling most of my product descriptions and names right off of vendors' web sites via copy and paste, and it's been copying those strange characters over, and to the eye, they appear to be apostrophes and quotations, but to the machine, they're not, because they're not the right ascii values :D that's why i could put 2 statements back to back to show a stripped version of a name i manually fed to the function and a stripped version of the name pulled from the db, and i got different results :D i've since gone through all of my products and replaced those, and they strip fine now :D Richard Lindsey.