Jump to content
Latest News: (loading..)

burt

Team
  • Content count

    13,076
  • Joined

  • Last visited

  • Days Won

    467

Posts posted by burt


  1. 18 hours ago, altoid said:

    PHP Notice:  Undefined index: osC_Action in /home/UserName/public_html/ext/modules/payment/paypal/express.php on line 63

    Both of these would need a code update to the module, which HPDL looks after.
    Put an isset in the osc_action, as so;

    switch ((isset($HTTP_GET_VARS['osC_Action']) ? $HTTP_GET_VARS['osC_Action'] : '')) {

    This may fix it, until HPDL gets back in the saddle.

     


  2. 18 hours ago, altoid said:

    PHP Warning:  Use of undefined constant OSCOM_APP_PAYPAL_LOGIN_SORT_ORDER - assumed 'OSCOM_APP_PAYPAL_LOGIN_SORT_ORDER' (this will throw an Error in a future version of PHP) in /home/UserName/public_html/includes/modules/content/login/cm_paypal_login.php on line 41

    https://github.com/gburton/Responsive-osCommerce/blob/master/includes/modules/content/login/cm_paypal_login.php#L41 
    is where it is saying there is a problem. 

    Your error is stating it is undefined, yet it is set up (defined) as part of the installation process at
    https://github.com/gburton/Responsive-osCommerce/blob/master/includes/apps/paypal/modules/LOGIN/LOGIN.php#L134

    I think that maybe if you uninstall the login module and then re-install it, it might fix itself.

     


  3. Of course core changes need to happen sometimes.  It's unavoidable, we have code that's almost 20 years old...
    There's no way around that old code sometimes.  Everyone knows that. 

    Sometimes things are changed for the better (did that just today in fact, but that's something not yet in the public eye).

    But where core code doesn't have to be changed - why change it ??  That simply doesn't make any sense...  That's all.  

    As for giving direct answers, all the info is in this thread. 
    All the Poster needs to do is read and apply, learn from mistakes and trial & error.

    Give a man a fish...and all that.

     


  4. You can do it any way you like, go right ahead.  Go ahead & change core code with all these IDs and Class's....

    • And then when you or the person you are giving advice to needs to update and has all these micro changes...they will find it difficult.
      Unless have remembered these micro-changes from months/years ago!  Unlikely...

    Or...

    • Do it the easy way, that's built in, that Raiwa and I came up with, that requires just a little more understanding of .css
      And have no problems when updating in the future.

    I know it is very hard to step outside of ones comfort zone, it's something I struggle with when learning new stuff as well.


  5. 4 minutes ago, JcMagpie said:

    This works

    div.cm-i-customer-greeting a.btn:nth-of-type(even) {
      color: #fff;
      background-color: #FF0000;
      border-color: #46b8da;
    }

    And yet again we go off at a tanget! My post is not about how to make the change its about finding what you need to change. As that was the question asked.

    No tangent.  Simply giving you extra knowledge so that you don't continue to give advice that is not correct.


  6. 6 minutes ago, JcMagpie said:

    Not working! but would be good if it did.

    Danger is also good solution but only if you whant to use the theme colors.

    My point was not how you change but how you go abouut finding what to change.

    Your point would be valid, except that you have a large hole in your knowledge (targetable css).

    As for "not working!" - I put "untested" for a reason.  Play with it.

    The idea of .css that works for one thing but not another is a fundamental weapon in a webmasters armoury.  I've covered this in the past on a tutorial type post, see if you can find it...it might be hard to do so as it was a while back.  But in general;

    <p>abc 123</p>
    <div class="whatever">
      <p> def 456</p>
      <p> ghi 789</p>
    </div>
    <p>jkl 999</p>

    with this .css

    div.whatever p { background: red; }

    would affect two of the 4 paragraphs, the two in the whatever div.

    Apply same concept all over shop-side osCommerce as most (all?) containers have a class that can be used for targetting.


  7. 1 hour ago, JcMagpie said:

    So if you need to change just one say the login button

    image.png.f4c9ae22668c29184597dc27e7e20d3f.png

    const MODULE_CONTENT_CUSTOMER_GREETING_GUEST = 'Welcome <strong>Guest!</strong> Would you like to <a role="button" class="btn btn-info btn-xs" href="%s">log yourself in</a> or would you prefer to <a role="button" class="btn btn-info btn-xs" href="%s">create an account</a>';

    All we do is give this button a unique id,---- id=”log2”

    ...

    It’s the same for any change you need to make.

    Or (note: untested), don't do any of that and instead ...  know that .css is targetable;

    div.cm-i-customer-greeting .btn:first-of-type {
      color: #fff;
      background-color: #FF0000;
      border-color: #46b8da;
    }

    Or, for changing the colour of a button (use bootstrap, piece changed is in red);

    const MODULE_CONTENT_CUSTOMER_GREETING_GUEST = 'Welcome <strong>Guest!</strong> Would you like to <a role="button" class="btn btn-danger btn-xs" href="%s">log yourself in</a> or would you prefer to <a role="button" class="btn btn-info btn-xs" href="%s">create an account</a>';

     


  8. On 8/15/2018 at 5:30 PM, rulegacy said:

    Stock orders database table contains 4 cc_ fields intended for data that may not actually be stored as per PCI DSS. Is it safe to remove those so that our card payment module couldn't write there?

    Your payment module cannot write to these fields unless it is specifically coded to do so.


  9. 3 hours ago, 14steve14 said:

    some still dont get it.

    Exactly what Steve said.

    Just in case, anyone doesn't still realise;

    Our german friends have stringent extra data/privacy/info rules that were in place prior to GDPR and they
    don't seem to understand that the rest of Europe does not have these same rules.   

    Put as simple as I can;

    • GDPR rules and regs apply to all. 
    • German rules and regs do not apply to all.

  10. 4 hours ago, JcMagpie said:

    This could be an interesting update to make to the checkout process as well as most forms on osC.  It would help speed things up if the form could auto complete, most people have details already on there phone and many have them on PC's as well.

    Discussion on this a while back; 

     

    It seems as though I abandoned it, though cannot recall why 😕 


  11. On 8/14/2018 at 6:40 PM, Gyakutsuki said:

    For me I am testing a new shopping cart called clicshopping, it's easy to choose what you want display or not and customize it. Also, the subscription is a little bit different.
    All system has a different approach to the funnel. That I know, it must clear and help the customer to finish this order.
    If a customer wants to buy a product, 1 or 5 step it's not a problem if all his clear, simple to understand; Some website doesn't make this approach and the customer after is lost inside the funnel and stop the process.

    Pretty shit that you have not respected copyright.  


  12. Just now, 14steve14 said:

    I think I will just let it slide, but if one person thinks that it makes you wonder whether others do as well. I have had some interesting conversations about GDPR with other businesses and its surprising, even on these forums, how some dont care about the regulations and are just carrying on as they would have before. I suppose it will take one huge fine to make people take notice.

    I agree.  I've seen some things done and said here and elsewhere which make me raise my eyebrow. 
    I really hope some people are saying things "for effect" rather than for real.

     


  13. Interesting!  Sounds like he misread the whole idea which is all about placing limits on what can be done with his data.  

    Depending on whether you'd like his custom, I'd send back an email outlining;

    • what GDPR is
    • that all companies are bound by it and that anyone who does not can do anything that they want with his data including selling it.
    • Whereas you specifically state what you will do with his data, and anything not mentioned is what you won't do.  

    But in clearer english than what I just wrote.


  14. You're missing the micro-adjustments I mentioned.  These would be performed in each modules template file.

    https://github.com/gburton/Responsive-osCommerce/blob/master/includes/modules/content/product_info/templates/tpl_cm_pi_price.php

    to (eg):

    <div class="col-sm-<?php echo $content_width; ?> cm-pi-price">
      <p><?php echo (tep_not_null($specials_price)) ? sprintf(MODULE_CONTENT_PI_PRICE_DISPLAY_SPECIAL, $specials_price, $products_price) : sprintf(MODULE_CONTENT_PI_PRICE_DISPLAY, $products_price); ?></p>
    </div>

    To remove the massive header div and instead put the content into a paragraph.


  15. 16 hours ago, 14steve14 said:

    There seems to be some difference of opinion on guest checkouts. 

    I prefer not to use them, the only major difference is a "password" and "DOB".  DOB is easy to turn off and if remove password from the discussion, what is left? 

    Name, email, address <-- all needed for posting the bought goods to the buyer.

    Shopowner could then use some type of system to allow customers to login even if they don't have a password.  Password-less login...possible?  


  16. 16 hours ago, ArtcoInc said:

    @burt

    If a customer won't agree to the T&C of the shop (ie: 'give consent'), does the shop have an obligation to fulfill the order?

    Just asking .... it's not like I'd choose to turn down an order ...

    M

    Personally, I would not allow a "potential" to become a customer unless they specifically accepted my T&C's.

    This then at least gives me a level of security both the day of the sale and into the future;

    Quote

    I bought this from you and you passed my details to Paypal! 
    Not only that you passed my details to UPS.  Blah blah blah

     


  17. Posted this elsewhere, but makes sense to have in this thread;

    At what point does a Potential customer become a Customer?

    • after they create an account?
    • after they actually buy something?
    • when they sign up to a mailing list?
    • something else

    That's an interesting question.  Maybe shopowners should have something in their T&C explaining at what point a person becomes a customer, that wouldn't harm anything to add it in, and maybe helpful in the future should you have to prove anything to anyone.

    Remember also that GDPR does not apply only to customers.  It applies to ANYONE who interacts with your site, it is just that most shopowners direct people to agree to GDPR T&C etc at some point after the potential customer has browsed products etc.

    Whichever point you determine a potential becomes a Customer... you MUST STORE the exact T&C to which a Customer signed up, why;

    1. In the future, the customer can examine the precise T&C to which he/she
      signed up and if necessary withdraw his consent.
    2. To show the GDPR authority in your country the exact T&C to which the
      customer signed up, if the customer complains to that authority.

    Another thing to think about is "Guest Checkout" - how do you solve the problem of the buyer giving consent per GDPR?  How do you record the data?  What happens if a customer says "no, I won't give Consent" - how do you record it?  You can't use their email address...you don't have a customer ID.  What do you do?


  18. It's pretty simple, just use common sense.  Common sense tells me I need consent to re-market.  How do I get that consent?  Perhaps a Tickbox on create_account might be enough, linked to acceptance of T&C.  In your T&C page have a paragraph about re-marketing.

    At what point does a person become a Customer?

    • after they create an account?
    • after they actually buy something?
    • when they sign up to a mailing list?
    • something else

    That's an interesting question.  Maybe shopowners should have something in their T&C explaining at what point a person becomes a customer, that wouldn't harm anything to add it in, and maybe helpful in the future should you have to prove anything to anyone.

    Remember also that GDPR does not apply only to customers.  It applies to ANYONE who interacts with your site, it is just that most shopowners direct people to agree to GDPR T&C etc at some point after the potential customer has browsed products etc.

    Whichever point you determine a potential becomes a Customer... you MUST STORE the exact T&C to which a Customer signed up, why;

    1. In the future, the customer can examine the precise T&C to which he/she
      signed up and if necessary withdraw his consent.
    2. To show the GDPR authority in your country the exact T&C to which the
      customer signed up, if the customer complains to that authority.

     


  19. Totally do-able, it is exactly as @raiwa says.

    Gallery 10 6
    Name 20 6
    Model 30 3
    Price 40 3
    Attributes 50 6
    Buy 60 3
    Reviews 70 3
    Description 80 6

    You are constrained by the DEPTH of the Gallery, so place a minimum height on this using CSS which would be placed in user.css

    @media only screen and (min-width : 768px) {
      div.cm-pi-gallery {
        min-height: 1000px;
      }
    }

    Change the min-height on this to better reflect your needs.

    You will then also need to amend tpl_ files for product_info, at the very least;

    • remove clearfix from reviews button tpl
    • restyle price as it would look weird as a h*

    Prior to the extra tpl_ change for price, you would end up with something like:

    ppl.jpg.d95c5ea7f3bd5910cf153bbb3554e888.jpg

    Of course, how this would look in XS...is debatable, and that is why you can micromanage the layout using those tpl_ files if you so wish.  My system for these modules uses only the SM layer.... however, that micro-management is where things get really complicated really quickly and hence why I did not put that level of management into Core.

     

×