Jump to content

GLWalker

♥Ambassador
  • Content count

    842
  • Joined

  • Last visited

  • Days Won

    37

Posts posted by GLWalker


  1. Hi everyone, thanks for the input thus far, I probably rushed into getting it ready for the BS Community edition, and overlooked a few things. If anyone is using the standard 2.3.XX download, use the first version I uploaded, should be fine.

    I'll make more changes and upload, I've been n the middle of a move, so this was my first chance back online since the last time I posted.

    As for the GitHub recommendation, I have been thinking of that too, so expect to see a repo soon.

    Existing order editing - this doesn't do that - but if there's enough interest it could.


  2. 3 hours ago, TITO4 said:

    · The file admin/includes/classes/http_client.php was missing. If I'm not wrong, it is not part of the last BS Edge version. Taken and added from previous Osc versions

    Just searched around on this file and it appears that it was only being used with USPS module, and it's outdated as well, so it was removed from the BS version.


  3. 13 minutes ago, TITO4 said:

    Hi G.L. Looks really nice. Thanks!
    Just installed and testing on BS Edge (August 2017), on Wamp Server. Issues I found:
    · I needed to change everywhere from DIR_WS_INCLUDES to "includes/.. etc.". The same with CLASSES, IMAGES, etc.
    · The file admin/includes/classes/http_client.php was missing. If I'm not wrong, it is not part of the last BS Edge version. Taken and added from previous Osc versions.
    · In php7 (v. 7.0.10), when clicking on Customers or Orders nothing happens, and the same when refreshing. It works if I delete in the URL the oscid (i.e ?osCsid=irl141pd59dngrhurivgsbh520). On the other hand, under php5 (v. 5.6.25) it works properly.
    · I remeber that I also had to change/correct something in Invoice and Packing Slip files. Sorry, but now I don't remember what.

    I'll continue testing it, and if you wnat, I'll be telling you what I find on it.

    Again, thanks!

    Ahhh, yes.. forgot about those changes for the BS edition - my most recent testing was on the standard 2.3.4.1 download. I'll make changes and update. Thanks for the feedback.


  4. This is the support thread for the Customer Service Portal  https://apps.oscommerce.com/xihXD&customer-service-portal

    The primary goal of the Customer Support Portal is to allow osCommerce shop owners to allow their employees to work on order fulfillment and customer support inquiries without having to allow direct admin access. Additionally it serves as a full fledged order placement system that will work with a shops existing payment methods, as well as a couple of new payment modules that could be useful in case alternate means of payment processing are desired, or in person cash sales are needed.

    The Customer Support Portal also allows  a true guest checkout option. No customer is created if this option is used. All customer information is stored only in the actual order information. There is a quick link in the Customer Portal Header menu that allows guest orders to be viewed separately from the rest of the store orders. Please note that in the ht_customer_service module settings there is an email field to fill out, by default it uses the store owners set email address. This email is used for certain functions within the Customer Service Portal, such as a placeholder email in guest account creation. It will always be populated on the guest customers information field, just to skip the additional step of gathering an email address from a guest.

    Whenever done with guest accounts, or even logging into an existing customers account always go back to the dashboard. This resets the session for that particular customer. If you are in a customers account, then you have to take on a session allowing you to access their info, the dashboard kills any sessions that are not related directly to you the customer service agent.

    If you are using the cash payment option, you will need to adjust the sort order of you order total module sp that the order totals and cash back amounts are computed correctly.

     

    Helpful Videos:

    https://www.youtube.com/watch?v=cwaid91cp1A&feature=youtu.be

    https://www.youtube.com/watch?v=dLgiD1FoTj4&feature=youtu.be

     

    Known issues:

    This plugin has been used in working shops for a number of years and proven to be stable. There are howver 2 issues I am aware of.

    1) If a product in the cart has attributes, the update quantity field wont work properly. If a different quantity is desired, just delete it and add the correct quantity from the product listing itself.

    2) I have not noticed this until testing on PHP 7.0, when using the cash payment option, the update button needs to be clicked twice.

     

    Feel free to post with comments or suggestions.


  5. @@ArtcoInc

     

    Is it the text or onHover color that changes incorrectly, either way, have you just simply marked that particular element in the style as !important? Looks like maybe .dropdown-menu > .dropdown > a:after, .dropdown-submenu > a:after  may need something like color: #cccccc !important

     

    More than likely an existing rule in the Bootstrap CSS is overriding it, its probably a matter of targeting that specific selector, even if it means applying the rules all the way into a nested level.

     

    May need to list all levels in the css to get it, like:

     

    .navbar-nav > li > .dropdown-menu > li > a:hover {

    your rules here

    }

    Or maybe just simpler with the Important rule:

    .dropdown-submenu > a:hover {

    your rules here !important;

    }


  6. @@kymation :thumbsup:

     

    Yes that is, Ive played with it and got so far, but I think its more powerful than just what that example shows - reading through the latest classes I see where it has actions and execution. I would to see how it would handle a page, like contact us for example, I want to see how it would route the output after the submit form action is initiated.

     

    Kind of like was started here:

    https://github.com/haraldpdl/oscommerce2/tree/24-checkout/includes/apps/info


  7. @@ShaGGy

     

    In addition, we'll have a compatibility module available for those upgrading that will wrap removed functions (eg database) and constants (eg filenames, database names) to the new framework changes. This should allow v2.3 modules to continue to work with v2.4.

     

     

    As mentioned, there will be compatibility. IMO - HPDL has been too generous in insuring addons have stayed compatible from version to version.

     

    Without a compatibility layer the minimal changes I foresee needing to be done to make an old addon work:

     

    MySQL queries  - They need to be changed to take advantage of the PDO driver. End result - faster & more secure.

    HTML functions - rather than tep_draw_*  it would change to HTML:: or OSCOM:: - End result - can easily be overwritten, extended, or replaced by including your own class.

    Defines  - No more more FILENAME_WHATEVER or TABLE_BLAH_BLAH_BLAH - End result, less processing by the program.

     

    Other than those things, the older addons can still follow the same installation procedures as before. However, with the newer framework, we wont have to hack the core and as a result we will probably start seeing better addons. I think that alone will attract more users, both shop owners and dev's.

     

    Ive worked on tons of osC sites through the years, I was inspired to become a web dev thanks to osC and a couple members on this forum, but I tell you - I'm also tired of hacking at core to do things. I try not too - I extend and bend where I can -  The new code base - beautiful - write a class, upload it, watch things change. BAM!

     

    If an end user doesn't want to use the program because it changed, they can and will find another software. But if the software doesn't change, they still can and will find another software.

     

    Really, osCommerce has been great through the years, your not going to find an ecommerce software with such a broad range of server compatibility and customization ready base. Look how many forks have branched off of osC. But now what are those forks doing? Nothing really, they have reached EOL - all the 500 addons they pulled straight from the contribution section has caught up with them. Now they are all outdated and osC is the only one that has advanced its code base so as not to get outdated, yet it also seems like osC is the one that has took the most crap. Can't win for loose they say.

     

    Anyway, as all can see, there is going to be compatibility, there is all the effort of the community build rolled in, and there is new modern code. Compare the new code to other open source software out there - Ive been reading it for 2 weeks straight. Its well ahead of anything right now. PHP7 - no problem, 2 years from now - PHP10  - probably good to go there as well.


  8. 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.

     

    I think there are a lot of opinions on what certified developers could mean. When I think about it, I don't feel as if it should be a requirement for submitting an addon, Anyone should still be able to write and submit an addon.

     

    I think of it more in terms that if you are certified, then that is something you can use to show the public that you know what you are doing with osCommerce code and they can have confidence in dealing with you on a commercial basis.

     

    A lot of things could define that certification, and if you/your dev company starts to do sloppy work, there could be a revocation of your certification.

     

    It would also help to have that little badge in the addons as well. Rather than have to click on @@Jack_mcs username and see a list of his downloads after I first find one of his downloads so I can click the name, I can just "sort by certified" and there are all his addons in the list.


  9. I, for one, am certainly happy to see the changes happening in OSC core.

     

    No more filename defines is freaking great. No longer have to write FILENAME_BLAH_BLAH_BLAH to keep in the projects standards when writing code. But besides that, the main benefit being less define(s) and interpretations. A small but beneficial micro-optimization.

     

    So someone found a bug, albeit a small bug that apparently reared its head on a 1.99 per month bucket host, still a bug. I see that bug was reported as an issue with link to how to correct. That's great. And it looks as though an answer was given that said the area it involves was going to change soon. What more is there to worry about?

     

    And that's all small stuff:

     

    How about that new code? Anyone been following HPDL's Git? IMO it's a little much, I would scale back some of the changes and rethink it a bit, However - its freaking good stuff going on. 100% F*#@ing great. All the new code is modern and following what standards we do have for PHP.  I guarantee its faster, better efficient, and has a long term future.

     

    So speaking of code and future, as a result of the new code base changes, every addon currently available will not work without being rewritten. But so what? I rewrite over 80% of things I find in the addons section anyway. osC has kept the core the same for far too long, and much of the reason has probably been to satisfy those who rely on the addons, or those who do not want to see a more modular way of installing addons. (You cant charge as much to push a $button).

     

    Its well past time to change core. Everyone knows it. There's those that welcome the change, then there's those that will bitch and cry-baby about it. In creating the responsive community edition, we've pretty much seen that. If the main core would have changed - what - 5 or 6 years ago, people would have bitched about their addons not working then, and devs would have cried about loosing business, but you know what? That would have been then, and now would look a lot different. Inevitably things are going to look different. 

     

    Good luck to osC, its great, and it always will be. One way or another.


  10. @

     

    The Scaffolding.less.css is because of css source maps - https://developer.chrome.com/devtools/docs/css-preprocessors for a brief on it.

     

    Loading all css in one file is also not recommended. While lots of information out there talks of minimizing and combining stylesheets, it only is helpful up to a certain size. Once your file gets too large, then load time becomes longer. Loading separate stylesheets offsets the load.


  11.  

    My primary point that I'm trying to make is that any (more or less) official demo site is the primary advertising for osC. If it doesn't look good, people won't go any further than looking at the cover, so to speak. They will use some other product with a slicker presentation. By all means load it up with add-ons and tune it up, so long as it's clearly stated what's been added or done to the out-of-the-box store. Offer some theme variations to show what can be done with it.

     

    I personally don't care if the demo products are stuck in 1999 or whatever, but if someone wants to put in the effort to update the inventory to current products and prices, that could be marginally helpful to someone considering whether or not to use osC. Just remember that the sample inventory should be kept updated (every 5 years or so, at most).

     

    Unfortunately a lot of new users wont ever see the trees for the forest. As we all know, the software can look like anything you can imagine, but too often users do not see that.

     

    Demo products are risky - there are all kinds of rights involved in their usage. An individual setting up a demo probably has no problems getting away with placing whatever products and images up, but an official repository would have photography usage issues among others.


  12. My admin BS is out there on GitHub. Feel free to pull it and deconstruct/reconstruct as needed. I laid it out in a way that still resembles the existing admin, just bootstrapped.  Nothing fancy, as the bells and whistles can be added later and as needed. 

     

    I have not had the time to complete the full admin, but have laid out what I think are the most difficult pages to remake, a majority of what is left are very similar in existing markup, therefore would be easy to run with once one started.

     

    Somewhere along the way of working on the admin my focus shifted back to the catalog side. I'll get back around the admin at some point, but its not critical as it is more than a point of reference and ideas of how to create the layout. As we have seen what is ultimately coming for osCommerce will be a more extendable admin area. Many files will change, while some will not.

     

    Perhaps what I have started will inspire a new look, or perhaps it will go beyond :)  Anyway it goes, the code it out there to be used as needed or as an example of what not is needed!


  13. I have recently worked on a template, using the structure I proposed. In making the header - as a content module - I came across an issue with using the <header> element. See I wanted to close of the header to make the breadcrumb move over to top of the bodyWrapper in line with the bodyContent area, and then apply style to blend it together so it looked like it was all part of the bodyContent div.

     

    So anyhow, if using header element, I would have to close the header, and then open a new header that would close further down inside template top - so ideally we should stay with the standard div tag for such things. The addition wrapper for BOOTSTRAP_CONTAINER was of no effect either way as it can be closed with in the header, or left open - all depending on the complexity of the design, but many ways to work with it becuase it is using a standard div.

     

     

    @@Dan Cole

    I have also noticed there are pages that need some tidy up and further use of the contentText class for a consistent design flow.

     

    @@burt

    I have seen a lot of bug fixes and tweaks coming through, so I will probably make a new for, apply what I have learned from the original proposal, and then go through and make the smaller tweaks as I just mentioned above. Some places we have divs with maekup like : class="contentText row" and that doesn't work very well as it changes the margins. I feel some of the button areas also need to be additionally wrapped with contentText.  All and all just for consistant design - some themers will never do a thing with contentText, while other will add classed to them for desired look.

     

    If anyone wants a quick view of what im talking about, add this to teplate_bottom.php

    <script>
    (function ($) {
    	$('.contentText').addClass('well well-small');
    })(jQuery);
    </script>
    

    Some of the main issues are within the account pages, so look around and you'll now easily spot what needs what.

×