Latest News: (loading..)

BrockleyJohn

♥Ambassador
  • Content count

    573
  • Joined

  • Last visited

  • Days Won

    21

BrockleyJohn last won the day on November 5

BrockleyJohn had the most liked content!

4 Followers

About BrockleyJohn

Profile Information

  1. @greasemonkey look what I found: A neat way to change PHP / MySQL timezones at the script level In a nutshell, if php is using the right timezone and handling daylight savings, just use the format of php date that expresses the offset from UTC to set the MySQL timezone: "SET `time_zone` = '".date('P')."'" Since MySQL always stores datetimes in UTC, your existing data will be magically corrected. So there are two statements for a complete solution date_default_timezone_set('America/Toronto'); tep_db_query("SET `time_zone` = '".date('P')."'");
  2. Hmm, maybe your mysql time zone is out of step. If I remember correctly mysql stores everything as UTC and converts it on the way in and out. It also has two time zones, a global one and one for each session. SELECT @@global.time_zone, @@session.time_zone; will find out what they are set to (if it's SYSTEM, it's the system timezone) SET time_zone = timezone; will set it but in my (admittedly limited) experience the timezone table isn't often set up, so you probably can't use 'America/Toronto' and will have instead to express it as '-5:00' (your time relative to me as I live 5 miles due south of the Greenwich observatory!) If you go down this route it'll need a bit of research into daylight saving, I don't know if mysql adjusts for it or not if you do this - your setting code might need to.
  3. @greasemonkey Scott, what server time issue do you want to fix? I gather there's a time difference between your server and your store but this addon isn't going to change the time on your orders etc. I think you should be able to sort that out by setting the correct time zone - the 'proper' way is in your php.ini Even if you are on shared hosting you can usually have your own version of php.ini somehow but in this case you'd probably need to get support to help you set it up - and if you want to change php version you'd need to redo it. That's the only option I can think of if you want to avoid changing any core code but if you're not being anal about that an easier option is to set it in the code - probably in your two application_top files. Your statement should be: date_default_timezone_set('America/Toronto'); preferably before anything much else happens.
  4. On the other hand, loading bootstrap from a cdn may save your first-time visitors loading most of the css if they already have it cached, and offer them a quicker load than you do anyway, depending on their location and that of your server. I hope you have already addressed image sizes and are running a high php version, your database is well-maintained and your sessions are getting cleared down. If you are running lots of addons it may be the case that you're running too many separate queries to build your page and it may be that you need it optimising in some kind of super-addon that combines them and shares data - but I'm guessing. Any of these would make a much bigger difference than combining the css. BS is already minified and custom.css is as small as possible without losing legibility. You are saving a couple of server requests but not much data.
  5. Hi Anne, htaccess works hierarchically. You can put it in either but if the top one it needs to be before the redirect.
  6. @Demitry apologies - sloppy checking. I've never seen that code path before; I don't believe I've had a BS client yet that doesn't use large images which is the only time that statement gets used. I had to go back remove the large images from my test product to reproduce. The reason it is originally there is to prevent a quote (or double-quote) in the product name breaking the page or throwing an error. You should check whether either breaks your change. This isn't necessarily the place to address it because the scope of the project is to provide a responsive variant of the main osc release. The more additional change that's done, the harder it is to bring this variant and the main release stream back together in the future. The only serious departure from this has been php7 compliance because of the strength of demand from BS-users. If there's a big problem that prevents people using the project for some reason, an urgent new requirement (eg for google, meta data etc) or something that makes it much easier to create addons without changing core code then maybe there's a discussion to be had but I don't think that what you're raising here falls into these categories. If changes are introduced for an issue that's carried through from the mainstream but which eventually gets fixed in a different way in the mainstream, that can create an extra migration issue for getting BS-based projects into a mainstream version at some point in the future.
  7. That's not from core. The core code is echo tep_image('images/' . $product_info['products_image'], NULL, NULL, NULL, 'itemprop="image" style="display:none;"'); Doesn't populate alt at all
  8. A big thumbs up from me. Getting the metamodel right is going to be tricky but it's a big step towards giving shop owners much more design choice without touching code. Of course the people who'll really benefit are the template builders. The killer app is going to be the visual editor that sits on the front and lets you interactively redesign your store.
  9. function execute() { global $PHP_SELF, $oscTemplate; if (tep_not_null(MODULE_HEADER_TAGS_GRID_LIST_VIEW_PAGES)) { $pages_array = array(); foreach (explode(';', MODULE_HEADER_TAGS_GRID_LIST_VIEW_PAGES) as $page) { $page = trim($page); if (!empty($page)) { $pages_array[] = $page; } } if (in_array(basename($PHP_SELF), $pages_array)) { $script = <<<EOS <script> $(document).ready(function() { $('*[data-in-stock]').filter(function () { return $(this).data('in-stock') <= 0; }).each(function() { $(this).addClass('disabled'); // use to change appearance $(this).attr('disabled', true); }); }); </script> EOS; $oscTemplate->addBlock($script, $this->group); } } } pop that in a header tags module (base it on the grid list one but change the names obviously)
  10. @ArtcoInc yes, but I'm going to test the code before I post it ;)
  11. You could disable the buy button if there's no stock...
  12. Even if it had, I don't think you'd see it there, as the content module would be treated as a different file. I don't think git understands moving a file, it deletes one and creates another somewhere else. But you're right, I don't think it got merged (so it's not my fault after all ;) I bet that's where his code came from, though.
  13. Yes - at some point it has moved back again. The thing is the noscipt module gives you an html error if you use it because the tag noscript only belongs in the body. Thus it needs to be a content module (now I look back, a navbar one not a header one). https://github.com/gburton/Responsive-osCommerce/pull/237 and https://github.com/gburton/Responsive-osCommerce/issues/181 ...it might be my fault - it's the sort of thing that might have happened in merging the php7 changes
  14. actually ht_noscript now is a content module he's got it in the wrong place - it should be in the content header group (and maybe Gary should have renamed it when he moved it!)
  15. v1.5 uploaded to the apps area and my github Fixes a bug spotted by @boelle where the tab text & link were being added to any bulleted list in the section - see attached image (Alle bestillinger is All Orders in Danish). Also included is the code simplification from @trier