Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by AlanR

  1. Modify New Product page to support image directories ------------------------------------------------------------ This is a simple modification to /admin/categories.php It adds a new field to the new product page named: Image Subdir. (images/...): just above the Product Image: field There is also a very minor change to /admin/includes/languages/english/categories.php. It adds only one line to define a new field name. This keeps the language defines stucture consistent with osC standards ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this field you can add the path to your image location, ie: /pets, pets/dogs, pets/dogs/brown and so on. Add the path in that field, browse to to the correct image on your pc and the file will be uploaded to the correct directory and the image file name in the database will indicate the correct location, ie: /pets/kitty.jpg. The operations are identical to using the standard categories.php but with the addition of image paths. Delete a product and the corresponding image is deleted. The directories must exist on the server, it will not create them and they must be writable. If they can not be found or or not writable the standard osC error checking will give you a warning. You'll have to know/remember the directory names (sticky notes are good). It's based on the 051113 update version of osC MS2 so it incorporates all current updates. The changes are fairly simple and most users are using the stock categories.php file so this can just be used in its place. There is one simple change to admin/includes/languages/categories.php to add the name for the field in keeping with osC language conventions. I've only tested this on Unix/Linux systems but from my understanding it should be cross platform (it uses forward slashes in php for the subdirectory pointing). The installation instructions are in the install document.
  2. The doctype declaration change from: <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"> to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> (which is correct) breaks the simple centering and fixed width fix with CSS which I know many, many, people are using. I was thinking of solutions for this and there are a couple but it would seem that the most logical fix would be to move all of this... <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html <?php echo HTML_PARAMS; ?>> <head> <meta http-equiv="Content-Type" content="text/html; charset=<?php echo CHARSET; ?>"> <title><?php echo TITLE; ?></title> <base href="<?php echo (($request_type == 'SSL') ? HTTPS_SERVER : HTTP_SERVER) . DIR_WS_CATALOG; ?>"> <link rel="stylesheet" type="text/css" href="stylesheet.css"> </head> <body> into the header and the corresponding ending code on every page... </body> </html> into the footer. That's the way that most sites are coded but I'm sure there's some reason, historical or otherwise that it's not that way. I'm sure this question has been raised before over the years but I guess I'll ask it again. I don't want to deviate very much from what will be coming as the base version in the next release since that will make my life more complicated. Answers from anyone?
  3. I haven't had much time to spend on it yet, other things got in the way. Ideally I'd like to keep the code as close to what's coming down the track but it's too early for me to see yet. It's easy enough to incorporate important stuff like security measures without moving totally towards the dev version but if the dev version ever turns into a release it would be nice to be close to it.
  4. Harald and Mark have introduced code which takes the development version of osC2 somewhat closer to this mod. I haven't yet looked closely enough at what they've done to see if their changes should be merged into my version. Move html layout to template_top.php/template_bottom.php; introduce dynamic per-file header tags modules
  5. has still not set his status

  6. Going back to my first post in this thread Just as a test I edited tp-boxfooter.gif, made it 156px wide, shoving the image to the right, leaving a white column 1px wide on the left. Fixes the problem in every browser I tried, Mac Firefox, Mac Opera, Windows Opera and didn't break any other browsers. So it's either accept that as a solution or create a new selector for the box footer. Neither solution is real elegant.
  7. Thanks very much. Reference is all I need, and all I can use really since I'm building on git source unless you are too. I'll do a compare and see how I match up. My immediate need is satisfied by the CSS conversion which I love and am very grateful for. I was dreading having to work with the tabled MS2 structure but now I'm wondering if a “Web 2.0” version “2.5” can be built. Update / Edit: I reread your post and realized that we are on the same page since you are building off the github master. If anyone wants my version of OSCommerce 2.2RC2a to table-less CSS I'll upload it and make it available.
  8. I'd like a copy too. I did all the other files, didn't take long but I skipped classes/boxes.php pending your reply.
  9. Super easy. Protect forms with a token ID that is assigned to a customers session You've already seen what happens to someone who tries to submit a form when the token is not supplied.
  10. I tracked down the cause of the problems on submit. I had missed a form creation parameter which tells the updated tep_draw_form function in html_output.php to request the data needed to satisfy the new tests. 14 files updated. Harald tracked down an unrelated issue which I had chased as a red herring in this thread. The new system is really much better, it will probably reduce the problems with the contact form being used for spamming to nothing, increasing security in many other places as well. It's overall much more secure than the 2.2a release.
  11. All fixed. Once I wasn't chasing the red herring of the session id constantly changing I tracked down the error and the changes I needed to make.
  12. I searched the github repository to try and find the commit which introduced this change but gave up so I'll post it here. I'll use login.php for the example but the problem is in several files which use a submit button. In the release versions you'll find this line... if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'process')) { In the github version it's been changed to this... if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'process') && isset($HTTP_POST_VARS['formid']) && ($HTTP_POST_VARS['formid'] == $sessiontoken)) { If I use the github version in its native form and allow my browser to accept cookies it works OK. I then updated a github version with the OSCommerce Online Merchant v2.2 RC2a converted to CSS mod and ran into trouble. The first thing I find is that I can't log in, the page simply refreshes. Leave the fields blank and the page simply refreshes, no error message results. I dug around and tried several things to see if I could fix the problem but I can't find anything. I looked to make the issue repeatable so others can see it without installing that mod and it's easy. I simply blocked cookies from the domain hosting the shops so as to force the session id into the url. The vanilla github install then displays exactly the same behavior, I can't log in. I like the additional tests and if there's a way to solve the problem and keep them I'd like to use it. As it is it makes osC very fragile, it seems that some small change can break it in as basic a place as log-in.
  13. Just another unrelated note. In the fix... @ini_set('session.use_only_cookies', (SESSION_FORCE_COOKIE_USE == 'True') ? 1 : 0); I noticed that “True” starts in upper case and I knew I'd seen and used “true” before in the db configuration table. Clearly it's not a big issue but it would seem there should be some consistency for fresh installs.
  14. Yes, that solves the problem with blocked cookies in the github “vanilla” version. Now I need to keep digging to see what's going on in the modded version. :angry: Update... Now at least I'm not getting a new session token for every click of the submit button when I try to log in on the modded version, so that's some progress. :)
  15. (Off topic) You might be interested to know that the CSS mod allows me to use... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> which I found fairly impressive for an osC install.
  16. I originally blocked cookies so I could easily observe the session token to try and figure out what's happening.
  17. I added the CSS mod code to a fresh github download using a file by file compare process (I eyeballed every change). I've rechecked my work with further compares more than once. Have you tried your github version with cookies blocked in your browser? As I mentioned I can run the vanilla github download without a problem as long as my browser accepts cookies, block cookies and it breaks. Later on I'll move both sites to a web server and see if the fact my installs are local makes a difference. I doubt it though.
  18. I'll add... Naturally I first tried simplifying the tests I removed && ($HTTP_POST_VARS['formid'] == $sessiontoken) then removing only && isset($HTTP_POST_VARS['formid']) No luck. I've looked all over to try and understand why new session tokens are generated for every request before I even get to code which will generate a new session token.
  19. It's kind of a wash. With a default stylesheet you simply have an “if” structure instead of an “if - else”. The one thing you can't let store developers do is to assume they can change selectors on the fly. In that respect it's better to think of any particular stylesheet as a constant.
  20. Here's a couple examples <link href="./styles/prosilver/theme/print.css" rel="stylesheet" type="text/css" media="print" title="printonly" /> <link href="./style.php?sid=9b911f947ab35d15612dc7fbe2eadf0e&id=1&lang=en" rel="stylesheet" type="text/css" media="screen, projection" /> <link href="./styles/prosilver/theme/normal.css" rel="stylesheet" type="text/css" title="A" /> <link href="./styles/prosilver/theme/medium.css" rel="alternate stylesheet" type="text/css" title="A+" /> <link href="./styles/prosilver/theme/large.css" rel="alternate stylesheet" type="text/css" title="A++" /> <link rel="stylesheet" href="http://www.dailykos.com/css/widewads.css" type="text/css" media="all" /> <link rel="stylesheet" href="http://www.dailykos.com/ads/adblocker.blogads.css" type="text/css" media="all" /> <link rel="stylesheet" href="http://www.dailykos.com/css/wpoll_neu.css" type="text/css" media="all" /> <link rel="stylesheet" href="http://images2.dailykos.com/images/admin/poll_table.css" type="text/css" media="all" /> <link href="http://images2.dailykos.com/assets/weekly.css" rel="stylesheet" type="text/css" /> <link href="http://images2.dailykos.com/assets/image_upload.css" rel="stylesheet" type="text/css" />
  21. You're right about different styles for different places. phpBB uses a sophisticated stylesheet system with the stylesheets “compiled” into the database. It's kind of like being able to edit the style sheet from the admin section. I use 6 or 7 stylesheets in phpBB but they all get merged into one in the db. You can achieve the same thing in a way by adding additional style sheets in other ways. I don't know about trying to change definitions on the fly from page to page, users will see unexpected results because some users will have the stylesheet cached in their browsers, it can't be trusted. You learn this real fast with phpBB, you have to purge your browser cache every time you tweak your stylesheet or else you won't see your changes. The solution for that is to add more definitions if a page needs different parameters.
  22. Actually the definition for STYLESHEET needs that odd return as well to keep the source code looking pretty.
  23. I was tidying things up a bit and it kind of offended me to use a variable name for something which is a constant so I put the stylesheet and the doctype definitions in configure.php, at the bottom, like so. define('DB_SERVER', 'localhost'); define('DB_SERVER_USERNAME', 'root'); define('DB_SERVER_PASSWORD', 'password'); define('DB_DATABASE', 'osc'); define('USE_PCONNECT', 'false'); define('STORE_SESSIONS', 'mysql'); define('STYLESHEET', '<link rel="stylesheet" type="text/css" href="stylesheet.css">'); define('DOC_TYPE', '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> '); ?> configure.php is the closest thing we have to a constants.php includes file aside from filenames.php and I didn't want to make things too complicated. Then I changed all occurrences of $stylesheet and $doctype to the corresponding constant names. The odd little return at the end of the DOC_TYPE definition forces the next line in the source down to the next line.
  24. I think Mark may need to revisit this change. I tried blocking cookies on the vanilla site based on the github version and it's impossible to log in. Could be this change makes the system too fragile, it's not just an issue with your mod. I'll make a note on the github commit.