Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by GLWalker

    1. MrPhil


      In that vein: Fly Me to the Moon https://www.youtube.com/watch?v=mhZ2X9znPxM and Bam, Pow, to the Moon!

    2. Peper


      hehe, i sometimes tell my little girl we are going to build a space rocket, relentlessly she always smiles at my silly comment.

    3. mattjt83


      Very cool! Thanks for sharing

  1. Pretty handy reference/cheat sheets for developers: http://overapi.com/

  2. @@CGhoST It can be made to work on mouse over fairly easy - there are a few different additional scripts out there, here is one: http://kybarg.github.io/bootstrap-dropdown-hover/
  3. GLWalker

    Admin header_tag modules

    @@mattjt83 I actually redid everything to use the catalog side for modules - its probably just a preference thing, but my logic is that we're already accustomed to uploading modules to the catalog side, what exist in the admin already is just the dashboard modules, other available code such as the PayPal app makes use of the catalog side. So that's the route I took. In doing so I changed back the include to original and it works well. I also removed the query for the admin_header_tags module and its running fine using the existing code in modules. I do have some kinks I'm still ironing out though after changing things, so should have my branch updated in a day or 2, time permitting.
  4. GLWalker

    Admin header_tag modules

    @@mattjt83 Finally had some time to get back to this. I have no issues running it so far. I am going to create a module for it that adds TinyMCE to the product and category description fields. Should now be able to do this with zero core changes -(outside of adding the osC_template class) One question, admin/modules.php - Line 140 - 143 What is the reason for changing include to include once? @@azpro Actually, there are a few files that could be shared both Admin and Catalog side. In doing so it would reduce the overall file size of the project. And it has been growing with the community build.
  5. GLWalker

    Admin header_tag modules

    That seems very logical. Easy way of using what already exist, osC_template, and avoids conflicts.
  6. GLWalker

    Admin header_tag modules

    @@mattjt83 Browsing the code, everything looks fine, I'll install it and test later in the day. I do have some concerns with pulling the osCtemplate class from the catalog side - What are the chances of collusion due to some files that are present in both the admin and catalog side, such as index and login? At present there would be no threat, but as the system is expanded to include header tags, even content, there could be some conflict. Anyhow, I'll have a play with it and brainstorm a bit. As some know I did have a nice admin fork going, which I ultimately decided to stop because I realized that the admin would ultimately need to undergo further changes, at the time the PayPal App was introduced, which warranted some admin changes and I was under the impression that more changes further enhancing the admin would follow. While a header tags/content system in the admin may seem like overkill as shop owners do not make changes to the admin the same as they would the catalog - I personally think it would help with code developers write and make installation of new addons easier for the shop owner - that coupled with the app system.
  7. GLWalker

    Admin header_tag modules

    You must be reading my mind. While working on some changes that require javascript, I thought to myself, "Self; This admin needs a header tag system just like the front end"
  8. Big thumbsup to all who have been working away at the Responsive Build and building addons for it.

    1. Dan Cole

      Dan Cole

      So where have you been?

    2. GLWalker


      Working new job. Congrats on Member of the Month!

    3. Dan Cole

      Dan Cole

      Thanks Gary and welcome back...you've been missed.

  9. New payment module - Realex Realauth HPP added to addons.

  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. 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. Recently Ive been developing a very large addon for store owners to allow their employess to use without having to give them access to the store admin. A employee may view and process orders, email customers, create customer accounts, edit ordrs, and take orders over the phone using its own built in checkout process. Orders can be made for existing customers or strictly guest. Anyhow, while using the mod, it dawned on me that I had esencially created a method of making guest orders for customers that call in and do not want an account. Any order took this way goes into a customer account that is stricly owned by the store, and the address books can be set to a higher number than the regular customer accounts. So I was wondering, with the couple of guest checkouts available, - 1 deletes customer info after checkout, the other flags it as guest and allows the guest to become customer later. I think for guest you should not keep account data if you tell them they are a guest! Why not create a simple flow for guest that is very unintrusive to the core code by: 1) Have a select guest option - when initiated a session is set, lets call it guest_order. If guest_order is set, then the customer_id is the same as the stores customer account. 2) After setting the session, the guest is then directed to the store's customer accounts address book process where they enter their address, with the session set there will also be two more fields in the address book, phone and email. 3) After filling out complete address info, then two more sessions are set for phone and email, they would work very much like the comments session. 4) Customer goes throught the checkout and when checkout_process is initiated it takes the session info for phone and email and inserts it rather than the stores defualt info. Then it clears the phone and email session. - Probably delete any address book entries made as well. But thats another area that would be handled by session assignment as well. 5) On checkout success guest_order session is cleared, order is done, customer can move on. All the while the guest_order session is set certian things need to be disabled, such as access to account areas. Most of this could all be done using a header tag module. The checkout process would need some editing to tell it if guest_phone/guest_email exist then insert this else default. Unless it is possible to override it with a header tag module - but I dont think so. Overall a lot less code changes, no database changes, and orders page would have all the info needed for contacting customer. So far as I can figure in this scenario, - only 2 to 4 core files to change. Or 1 file, checkout_process, and then add new files for the address book/checkout new address selections. Thoughts?
  13. @@wHiTeHaT Yes I have noticed the original category_tree would not generate the correct path for nesting. Therefore I extended my version to make up for it. I would however like to see the repaired category tree added so that we could better work with the output for unlimited types of menus. Perhaps you could submit it as a bug fix?
  14. @@wHiTeHaT But some of us do, and have given instruction so anyone else can as well. @@Gergely multi submenu also solved. See my post: http://forums.oscommerce.com/topic/398284-oscommerce-23-bootstrap-nav-menu/
  15. 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!
  16. @@burt Per my previous post, I would like to make a proposal for slight change to the template structure/markup for better theme control and overall layout. Ive been looking at a lot of the bootstrip examples and do feel we would be more on target by changing the structure to follow as outlined below: <!DOCTYPE html> <html> <head></head> <body> <nav>navigation_content</nav> <div class="row"> <div class="col-sm-12">messageStack_header</div> </div> <header id="modular-header" class="BOOTSTRAP_CONTAINER"> <div id="header" class="row"> header_content </div> </header> <section id="bodyWrapper" class="BOOTSTRAP_CONTAINER"> <div class="row"> <div id="bodyContent" class="col-md-* col-md-push-*"> <div class="row"> <div class="col-xs-12"> <div class="alert alert-danger">error_message</div> </div> </div> <div class="row"> <div class="col-xs-12"> <div class="alert alert-info">info_message</div> </div> </div> <div class="contentContainer">main_content_per_page</div> </div> <!-- bodyContent //--> <aside id="columnLeft" class="col-md-* col-md-pull-*"> boxes_column_left </aside> <aside id="columnRight" class="col-md-*"> boxes_column_right </aside> </div><!-- row --> </section> <!--bodyWrapper--> <footer id="modular-footer" class="BOOTSTRAP_CONTAINER"> <div id="footer" class="row"> footer_content </div> <div id="footer-extra" class="row"> footer_suffix_content </div> </footer> </body> </html> Pay no emphasis to the HTML5 elements, they are only there for empahasis! Basically every section would have its own container wrapped around it, yet eveything is still stackable and in order. row classes have been inserted where need be before any dections that would use a col-sm-* class error and info messages have been moved down after the bodyContent opening div to place them better into the view of everything and avoid breaking design by having them float under the header. id's applied to each section mainly for design purposes, and allows to set the bootstrap contianer for each section - wait thats design! I only wonder if placing the footer and footer-extra into one container should be broke into 2 parts, so that the footer-extra has the ability to act like the top nav with nothing wrapping it but itself. I really wouldnt even include the header and footer anymore either, just the code to grab the content. So thats my proposal of the day, have tested it on my local and everything lays out as were used to seeing.
  17. 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.
  18. In cm_header_search.php We seem to have an out of order div $search_box = '<div class="searchbox-margin">'; $search_box .= tep_draw_form('quick_find', tep_href_link('advanced_search_result.php', '', $request_type, false), 'get', 'class="form-horizontal"'); $search_box .= ' <div class="input-group">' . tep_draw_input_field('keywords', '', 'required placeholder="' . TEXT_SEARCH_PLACEHOLDER . '"') . '<span class="input-group-btn"><button type="submit" class="btn btn-info"><i class="glyphicon glyphicon-search"></i></button></span>' . ' </div>'; $search_box .= '</div>'; $search_box .= tep_hide_session_id() . '</form>'; Should be: $search_box = '<div class="searchbox-margin">'; $search_box .= tep_draw_form('quick_find', tep_href_link('advanced_search_result.php', '', $request_type, false), 'get', 'class="form-horizontal"'); $search_box .= ' <div class="input-group">' . tep_draw_input_field('keywords', '', 'required placeholder="' . TEXT_SEARCH_PLACEHOLDER . '"') . '<span class="input-group-btn"><button type="submit" class="btn btn-info"><i class="glyphicon glyphicon-search"></i></button></span>' . ' </div>'; $search_box .= tep_hide_session_id() . '</form>'; $search_box .= '</div>';
  19. Disadvantaged children need your help to buy video game systems and other items of no real value. DONATE NOW

    1. MrPhil


      OK, I have some disadvantaged children. Where should I mail them?

  20. It looks like some info is missing in the database table. Its trying to merge info from various tables, but in one table or another the info is missing. Check the data inside both reviews and reviews_description table and make sure that you have a row of data with matching review_ids in each.
  21. I had to look back and check myself, heres my results: In short, an aside is anything that contians something that can be referred to as a side note or information away from or related to the main content. Even a blockquote can be marked up in an aside and it is considered proper markup. - However - upon revisiting some prevoius info on aside, and having the understanding of it I did not quite grasp when I started using HTML5 a few years ago, I will ditch the side column markup as an aside and go back to the div element. Though no harm would come in using aside, the actual use of it as a side column would be amatuer. Items that would be better represented as a aside in existing build would be things such as the product_reviews content module, best_sellers, manufacturer_info, anything directly related to the product or category being viewed, or somehow related to the site in the same way the product/category being viewed is, such as a list of links to sub categories, or related products <-- though that can be argued, but much of HTML5 can be. I'll change the commit again! :)
  22. No harm leaving the header and footer files, the code placed in template_top and bottom would just be moved into those files, much like it was before but with the addition changes for wrapping the area. My main thought on doing away with those files was the .00000001% gain by not having to include 2 more files, and looking at the previous column left and right that were removed in favor of the code directly in the template_bottom file. I will change the struture on my fork and resubmit. I would however like to know thoughts on using HTML5 section, header, and aside elements. We do already use nav and footer elements, so it seems that adding in the other markup makes sense to those, both human and bot, that follow HTML5 standards.
  23. You know, in admin we have the define_language tool, works well for those who may not have external editing tools. I was wondering if such a beast could be made for editing template files! Ive viewed over things but cant get my head around how to pick only the template files in each content directory. Just thinking out loud.
  24. @@burt Yesterdays proposal pushed for you to view. As for closing the 2 above issues, that should be fine untill further modularization happens, though they are probably 2 of the most editied parts of the site and adding them to template files would defienetly be the way to go.