Latest News: (loading..)

ShaGGy

Members
  • Content count

    111
  • Joined

  • Last visited

2 Followers

About ShaGGy

Profile Information

  • Real Name
    Les

Recent Profile Visitors

10,142 profile views
  1. @@MrPhil @@GLWalker as Phil is saying gradual transition is essential from what i gather the 2.4 (or whatever number will be used) 2.3.4 computability will cease? although we all agree OSC needs bringing upto date such a cold sharp shock to existing users will undoubtedly destroy future confidence (keep in mind these are businesses on low budgets that's why they install and learn OSC) and to suddenly leave them in the cold with a non responsive cart (bad) or force them to loose their website they have built and customised with the features they needed to function is also bad especially if this will involve relearning everything from the start as the changes are so big. I would slow down on major overhaul and introduce a number of gradual changes that head towards the end goal so as users can upgrade and adapt to the changes. Like changing the filenames.php simple change that could have been a sub version and users could then make the changes fairly quickly without breaking their sites, then release the next step (whatever it may be) that they can then incorporate (like we are doing via the git releases). if you suddenly jump to a completely new and incompatible version in the next public release what are your existing user base supposed to do?
  2. Totally agree if you look at some of the 'think out of the box' addons would they ever have been created if only CERTIFIED uploaders were writing them? Surely if they are that good then they are not going to be sitting there coding addons for free that they will never use themselves, I would say a large majority of addons only exist because the developer of the addon needed that feature for themselves and wrote it and then shared it (even though it may not be the best coded addon and as someone above said they then download it tweak/fix it and uploaded a revised version). take this facility away and as @@Jack_mcs says That would probably cause updates to slow or be stopped and I would add limited (would all the various shipping company modules from all over the world been there if the Certified developers were only in one or two countries.
  3. You mean certified to submit addons? if so i think that might be a bad idea as why write modules for OSC if you have to become certified you may as well write for one of the others and be paid for the addon. if anyone can submit a addon but it is checked before being released in the addons section that would be a better idea as it will promote the community spirit (maybe have a uncertified section for those who like the addon and can later verify it as safe or tweak/better it (i.e have certified people who can say 'YES' this one okay for release to the general public)) or maybe have flags in the addons section like. certified .. check and have a number of users who are able to verify a addon as conforming to code.
  4. Burt if you read my post i have said I have moved on from the {} issue and to be honest it makes no difference to me as I have already fixed the issue on my install. My post was more aimed at the fragmentation of OSC at the moment i,e modules wrote only weeks ago no longer work due to the filenames change and is there any point in updating modules to be BS comaptible when you have said you will be overhauling the attribs section? I was more concerned that you have moved onto the admin side when there are clearly things remaining on the catalog side that you intend to do and would it not be prudent to do that side first so that the modules can be updated to the point where they won`t break the customer side of osc in future changes? I wanted to install and update SPPC with QPB which was a nightmare to get fully working but is there any point if you are making further price/product related changes in the future which will undoubtedly break the addons, yes the admin side would break also but at least it wont shut sites down. The only other option is to stay static and not install modules (if you are not PHP savvy). To be honest would you recommend OSC for a new website in its current state 2.3.4 non responsive (bad) but modules work (good) 2.3.4 responsive (good) but most modules don`t work (bad) and cant really release updates due to ongoing changes. or install a rival cart that does both of the above? Like I say it doesn`t affect me personally I am thinking of OSC as a brand and its future as you know once someone changes to a new cart and it works they are unlikely to move away from it. Please don`t take what i have said personally it is NOT a ATTACK on you or your work I am just thinking from a users point of view.
  5. Read above, I did (actually the same bug/bad code is in the non responsive version) and yes I have found where the problem is and patched it myself and it is working fine on mine. (which was the passing of { } in urls with attribs which is advised against (like i said I have fixed this on my install) so not an issue for me.) My post was more for the future of OSC, its okay for those of us who can fix an addon or modify code to do different actions but what about the ones who don`t know PHP? The reason Burts making the changes (apart from the responsive part) and changing to modular is so there is no need to modify code when installing and un-installing addons (i.e make it easier for users to install addons like megento has). My concern is OSC is either going to become static/stale having either a non responsive version that is not ideal to install in this day and age or have the responsive version unmodified as the core keeps changing and even most of the most recent BS addons no longer work without modification. Burt as said in his response the attribs will be overhauled in the future, now think of the implications with that and how many addons use pricing,attribs, discounts, etc etc they will all be affected so is there any point in developing/updating any of the addons that currently are not responsive compatible especially if they involve any form of pricing/attribution features? Like I said I don`t need the fix and will be able to get around the future changes but what about the ones who want a responsive site but can`t identify issues and fix code? They have two options Non responsive OSC or install another ecommerce. I just think fixing the customer facing side first should be priority and any core code for that side and jazz up the admin side later. I have recommended osc to many people in the past but to be honest I would not at the current time unless I was maintaining it.
  6. Well I opened it as an issue in github but Burt closed it with the reply 'The whole attributes system will be receiving attention at some point in the future. In the meantime, if anyone else has similar issues, they can refer to your link. Thanks' I am unsure as to how they are mapping out the future of oscommerce as this says to me that it is pointless installing responsive OSC as it will keep being overhauled and modifying your site could be very difficult until it is developed fully. They have moved onto the admin side when there are things that NEED to be in place for the Shop side first if you look at the reason to close the issue 'if anyone else has similar issues, they can refer to your link.' this does not fix a fundamental coding issue that is documented as bad programming and inadvisable why not fix these CORE issues first as doing them later means yet again addons being developed will cease to work (like all the current ones dues to the filenames.php being made redundant) and 'The whole attributes system will be receiving attention at some point in the future.' sounds like more things will be broken as look at how many modules are products/price/attribute related (like SPPC&QPBPC). I love OSC but i do have concerns that if the development continues as it is it will do a lot of damage to OSC's future as as we all know Responsive/mobile compatibility needs to be in place now for sites to be accepted by google 2.3.4 (standard) is not responsive and the responsive versions are constantly changing and breaking the latest modules that were wrote for it then when you look at competitors like magento etc they are now fully responsive from the off. This isn`t a moan but @burt @Harald Ponce de Leon please look at how you are taking this forward so as not to discourage users and future users, I know it is a difficult task to upgrade/transistion a system while it is use and full respect for what you are doing.
  7. I have only made 2 simple changes in shopping_cart.php (urlencoded the links) but there may be other core changes that are/will be affected by this, I am currently configuring my new site so haven't seen if it affects anything else. But it does need looking at for the future. edit : I have added it to the issues in github.
  8. @@burt @@Harald Ponce de Leon Looks like there is a genuine reason for the core to be changed to reflect this for future compatibility, would not be good for OSC to start failing in the future and getting a bad reputation if it can be fixed before people upgrade or install responsive versions.
  9. I received a reply from my host @@burt would it not be prudent to urlencode() these urls from a core level to increase compatibility with hosts? I have patched my shopping_cart are there any other occurences of where the attribes {x} are passed in the url so I can fix them?
  10. Thats what i have done but only on the two functions (remove from cart and product link in cart) will see if @@burt thinks it needs changing in core as it breaks on my host and possibly others. I tried on php 5.5 & 5.6
  11. I fixed this by changing in shopping_cart.php $products_name .= ' <td valign="top" align="center"><a href="' . tep_href_link(FILENAME_PRODUCT_INFO, 'products_id=' . $products[$i]['id']) . '">' . tep_image(DIR_WS_IMAGES . $products[$i]['image'], $products[$i]['name'], SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT) . '</a></td>' . ' <td valign="top"><a href="' . tep_href_link(FILENAME_PRODUCT_INFO, 'products_id=' . $products[$i]['id']) . '"><strong>' . $products[$i]['name'] . '</strong></a>'; to $products_name .= ' <td valign="top" align="center"><a href="' . tep_href_link(FILENAME_PRODUCT_INFO, 'products_id=' . urlencode($products[$i]['id'])) . '">' . tep_image(DIR_WS_IMAGES . $products[$i]['image'], $products[$i]['name'], SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT) . '</a></td>' . ' <td valign="top"><a href="' . tep_href_link(FILENAME_PRODUCT_INFO, 'products_id=' . urlencode($products[$i]['id'])) . '"><strong>' . $products[$i]['name'] . '</strong></a>'; and $products_name .= '<br>' . tep_draw_input_field('cart_quantity[]', $products[$i]['quantity'], 'style="width: 65px;" min="0"', 'number') . tep_draw_hidden_field('products_id[]', $products[$i]['id']) . ' ' . tep_draw_button(CART_BUTTON_UPDATE, 'fa fa-refresh', NULL, NULL, NULL, 'btn-info btn-xs') . ' ' . tep_draw_button(CART_BUTTON_REMOVE, 'fa fa-remove', tep_href_link(FILENAME_SHOPPING_CART, 'products_id=' . $products[$i]['id'] . '&action=remove_product'), NULL, NULL, 'btn-danger btn-xs'); to $products_name .= '<br>' . tep_draw_input_field('cart_quantity[]', $products[$i]['quantity'], 'style="width: 65px;" min="0"', 'number') . tep_draw_hidden_field('products_id[]', $products[$i]['id']) . ' ' . tep_draw_button(CART_BUTTON_UPDATE, 'fa fa-refresh', NULL, NULL, NULL, 'btn-info btn-xs') . ' ' . tep_draw_button(CART_BUTTON_REMOVE, 'fa fa-remove', tep_href_link(FILENAME_SHOPPING_CART, ' products_id=' . urlencode($products[$i]['id']) . '&action=remove_product'), NULL, NULL, 'btn-danger btn-xs'); this seems to be working but probably not the ideal way to do it?
  12. @@burt @@MrPhil You got it, I amended the remove url from shopping_cart.php?products_id=1{4}1{3}5&action=remove_product to shopping_cart.php?products_id=1%7B4%7D1%7B3%7D5&action=remove_product and it works so it related to the {x} in the urls.
  13. In my case it does not redirect it stays on the cart page. I have placed some print_r in shopping cart and it appears the action=remove_products is not being passed to or reaching application_top which again points to the url containing the attribs part {x}x{x}x is failing as the action functions on items with no attrib parameters in the url. I did have a look through the php.ini last night for any setting that might be having an affect but could not see anything that it could be (I'll have another look today).
  14. @@burt I have been trying to get to the bottom of products with attributes not removing from the cart although i am convinced this appears to be an issue with my host affecting urls with the attrib {x}x{x}x part they say it is a oscommerce issue and the logs show shopping_cart.php PHP Warning: Unknown: function '1' not found or invalid function name in Unknown on line 0 I have installed the same install on a free host and it works fine. Is this a issue with OSC ?
  15. By 'Home Page' I mean OSC front page. I have searched and can only find one that had any form of replys but that appears to have been a seo add on he had installed and there wasn`t a resolution to it. I am convinced even more after today that something on my host is having an issue with the attribute part of the URL it almost as if when you click remove in the cart it doesn`t even run the action. if you set qty to zero it then removes it I have traced it to the point where if a item in the cart as attributes and the URL contain {xxx} then the remove_product function does not trigger in application_top. I replaced the whole remove_product function with $messageStack->add_session('product_action', sprintf(PRODUCT_REMOVED, tep_get_products_name($HTTP_GET_VARS['products_id'])), 'warning'); then added two items to the cart one with attribs and one without, if i click remove on the one with nothing happens, if i click remove on the one WITHOUT attribs the message is displayed, so shopping_cart.php is not passing the action through to apllication_top.php when theres a attrib. Sleep time 7.30 am :( i'll have a look at shopping_cart.php later.