burt

Really? It would be removed.

In your Admin Area there is a setting that allows the redirect to cart to be turned off. You can try that, it still refreshes but stays on the page the buy button is on. As an alternative, as @Tsimi rightly says, you could try Ajax. I experimented with something, you can try it http://template.me.uk/234bs3/index.php - this is just to prove it is do-able, it is not currently available as an addon.

And for the third problem, the link which @14steve14 links to has a solution, but again it's something that needs to be updated by HPDL. As well as updating HTTP_*_VARS to _* as well 😕

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.

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.

Slider Chit-Chat moved to https://forums.oscommerce.com/topic/492444-sliders-aka-carousels-yes-or-no/ Please continue that discussion there.

YES! Thank You Fred, you're a star.

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.

A while back someone posted a link to an external site where it showed a list of bs v3 .css etc that had been either removed or changed in bs v4. Does anyone remember or can find that post? Thanks

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.

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

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.

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>';

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

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.