• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About kantarou

  • Birthday 01/03/1985

Profile Information

  • Real Name
    Matt Jaskulski
  • Gender
  • Location

Contact Methods

  1. Hello. Sorry for replying so late. I don't enter the forums unless I have some issue myself :) Kira - this contribution does not affect the product listing. It does not affect the products database table either. It is "encapsulated" inside an infobox on the product page so it schouldn't even mess things up there. I think that your issue might not be related to Family Products. In case you still need a solution, please elaborate :) Kat - if you can't find such a file then you do not have STS installed. It is a greatly useful contribution. I think you schould install it. In case you don't want to you can try to change the infobox into a module. It requires a little bit of OSC experience. All in all - my client has been happily using this contrib for a while now and has had no problems. Sure - it could be a lot better, but as it is it gets the job done just fine.
  2. Hello everyone. I just posted a new version of this contribution (v 4.0). Check it out if you feel like it. Cheers, Matt
  3. Hello. First of all thank you for this great contribution. I've got a problem. I installed it and everything was working fine. Until it stopped admin-side. I am unable to insert, inherit or reciprocate any products. I blanked the database table 'products_related_products' and I noticed that nothing is being put there by the 'optional_related_products.php' script. I'm going to start looking through the code to figure out what got messed up. Did anyone encounter similar problems? I could use being pointed in the right direction :) Thanks in advance. ********EDIT******** I figured it out. Sorry :) I mistranslated the .php file because several of its items dont have their translations in the language file. So I guess... beware of what you are doing and always backup! :)
  4. Hello :) I had this error: Fatal error: Cannot redeclare tep_header_tag_page() in /sklep/includes/functions/header_tags.php on line 15 While accessing an article. To correct it i commented out this line in article_info.php: if ( file_exists(DIR_WS_INCLUDES . 'header_tags.php') ) { ;// require(DIR_WS_INCLUDES . 'header_tags.php'); } else { This seems to have solved the problem but I am afraid whether this is such a good idea? Are there any consequences that might show up that I am not aware of?
  5. NAIS, don't stick to line numbering. Find in your index.php a section that is responsible for displaying the page heading (in the text, not the header/title)) Most probably it will feature a constant HEADING_TITLE. Once found, place it inside a <h1> </h1> tag and you are done. This modification is not essential for this contrib to run. It's important for it to run efficiently. And yes. This contrib is the best one.
  6. In case someone was looking for a solution: sort_2a | page_1 etc is generated in the includes/classes/preventDuplicates.php class you are using along with this contribution IF you installed SEO Urls contribution and perhaps in other cases too. Obviously this has little to do with 'Header Tags SEO' contribution. Look here: http://forums.oscommerce.com/index.php?showtopic=314234 for the support for 'preventDuplicates' contribution and ways to combat the aforementioned ghastly topic prefix ;P Cheers, Matt
  7. Uhm. I have a question though -> I noticed that I get a ghastly 'sort_2a | page1 |' stuff. Previewing index.php in admin shows that entire title is preceded by a mysterious 'language_en' string. I wanna get rid of it! How do I do it? Should I? Googling it returns a bunch of seemingly incorrectly modded oscommerce shops and no solutions. Any insight would be appreciated :)
  8. Hello everyone! First let me say that this is one hell of an awesome contribution! Both thumbs up for you Jack (not that you do not deserve three or more thumbs, it's just I've got only two to spare :P) I'm using an STS enabled store. I couldn't make this contrib work for the Index.php page. The installation files are missing one instruction. The "headertags.php" file must be added BOTH to the 'default' and 'index' modules in the STS menu. Another thought - breadcrumbs are blank until filled using the admin part of this contrib (which gets installed waay later on). This freaked me out and made me redo the Catalog installation. Perhaps it'd be a good idea to mention it someplace. Thanks for this superb piece of code! Matt
  9. Thank you Kevin. I had the very same problem and your hint saved me a lot of time :)
  10. Thank you Lindsay. I had looked through this entire thread before posting and also had seen what you pasted above. Unfortunately this does not solve the problem for me. No matter what charset (utf-8 or iso-8859-2) I use (and I am modifying both attributeManager.php and requester.js) I always end up seeing these ugly "%uXXX"'s.
  11. Addon to the last post: I found the file javascript/requesters.js and there the code I was looking for: var e=(document.charset||document.characterSet||'ISO-8859-8-i'); this.commInterface.setRequestHeader("Content-Type", "text/html; charset="+e); this.commInterface.setRequestHeader('Accept-Charset',e) As I understand it, this contribution schould already be 'polish chars' friendly. I tried hardtyping 'utf-8' in there but the problem remains - all polish input gets saved as %uXXX combinations. Does anyone have an idea how to correct this? Any help would be greatly appreciated.
  12. Hello. First I'd like to join others in saying: whoa - this is an amazing contribution :) I've got this problem. I am saving polish characters and getting stuff like this: test %u0105%u0119%u015B%u0107%u017A%u017Có%u0142%u0144 instead of proper attribute names, etc. Some time ago Nimmit wrote: "...If you are parsing non latin charicters from javascript to the server you will also need to add setRequestHeader("Content-Type", "text/html; charset=ISO-8859-1"); to the request object..." And I don't know how to just do that. Can anyone help? P.S. My idea for a quick fix would be a function: function polishChars($str) { $str = str_replace("%u0142", "ł", $str); } But I am clueless as to where to apply it.