Jump to content

burt

Team
  • Content count

    13,552
  • Joined

  • Last visited

  • Days Won

    524

Everything posted by burt

  1. burt

    Email queuing system

    I believe this is now ready to test, if you are able to spend 5 minutes to create an account and perform a checkout I would greatly appreciate it: https://template.me.uk/outgoing/ Please *please* use a real email address as part of the testing will be viewing emails when they come to you to ensure that they contain the correct (ie, your!) data and letting me know of any issues. This system has as standard: birthday greetings sent X days prior to the customers next birthday [default: 21 days] no checkout sent X days after creating an account (and not checking out) [default: 5] request review sent X days after an order is made [default: 60] winback sent X days after the customers last order (or create_account if no order) [default: 365] Where X is a number of days defined (per module), default as shown. Each could be changed by shopowners as needed; perhaps some shopowners might feel a year later for "winback" is too long - in which case set it to (eg) 90 for the email winback to fire off about 3 months after last. Etc and so on.
  2. burt

    Only Show Boxes on Selected Pages

    That piece of code should make sense and is portable to box(es) for 100% sure. It might be practical to move the function into (say) /includes/functions/general.php and then just access that function from the module (rather than having the (basically the same) function in all the box modules). Hope that makes sense. If you do that, and get it working, hit me up with it as it can go into Core. Thx.
  3. burt

    Only Show Boxes on Selected Pages

    You have two (easy) ways to do it; Set pages per box or Set boxes per page I'd set pages per box as there are less boxes than pages so it would be a lot quicker... You can find an example of this approach in /includes/modules/header_tags/ht_datepicker_jquery.php Or you have a more flexible way (but needs coding from scratch); create a new DB table for storing page/box relationships. And then have a dedicated admin page for setting it up.
  4. burt

    Email queuing system

    Adding in those extra {{XYZ}} tags has caused problems. Main problem being on the admin side when adding an email into the Queue, the extra {{XYZ}} tags over and above the basic (always available) ones were impossible to add. That's now solved after much banging of head on keyboard. So, I think it's now good to start being properly tested - over the weekend I'll upload the new files to the demo site, clean out the queued emails and ask for testers (once again, sorry)...
  5. burt

    Email queuing system

    Another full day of coding this, the joys of being a coder. I now have it as easy as possible to add in {{XYZ}} tags, and they automatically show in the admin side as available for use. Eg on the "no_checkout" slug I added in {{SIGN_UP_DATE}} (which is the date customer created account) and in the admin side it appears like so ready for use; It's not as simple as I'd like, but I think I've done as much as I can working within the confines of the osCommerce architecture...
  6. burt

    Email queuing system

    This has turned into a bit of a nightmare. By adding in those extra {{XYZ}} tags I made it almost impossible for users to *easily* extend the system further. 😕 So, I've recoded that portion (again [that's three times now]!) and it is, at last, as smooth as silk. However making it that easy on the shop side... has broken the admin side functions. So I now have to recode portions of that 😕
  7. burt

    Sitemap SEO

    I've not used this particular SEO sitemap, but here is some quick and easy code to try - this will output an array of data so that you can basically do whatever you want with it... $c2p = array(); $category_2_product_query = tep_db_query("select p2c.*, p.products_image, pd.products_name from products_to_categories p2c left join products p on p.products_id = p2c.products_id left join products_description pd on p.products_id = pd.products_id where p.products_status = 1 and pd.language_id = '" . (int)$languages_id . "'"); while ($category_2_product = tep_db_fetch_array($category_2_product_query)) { $c2p[$category_2_product['categories_id']][] = $category_2_product; } $_tree = new category_tree(); $tree = $_tree->getArray(); foreach ($tree as $a => $b) { $c = end(explode('_', $b['id'])); $tree[$a]['products'] = $c2p[$c]; } echo '<pre>'; print_r($tree); echo '</pre>'; I do not know if that will be useful to anyone but it may give ideas...
  8. burt

    Email queuing system

    I haven't. I'm aiming to get something useable for "out of the box" osC...and then if individuals need technical advice/changes, I'm available as usual. Long story short, for something like PWA (note that I do not know exactly how PWA works but have a general idea), it would just mean working out what data is available and creating a an outgoing-email module for that data. To make a long story even shorter; not difficult I think. As for something like a winback (or any other outgoing-email module) that would be up to each shopowner to decide what is right for their demographic...as simple as that...
  9. burt

    Email queuing system

    OK, I've now added in some extra data points for birthdays and for review_request; Birthday, you can do (eg): Hey {{FNAME}}, it's your birthday on the {{DOB_DAY}} {{DOB_MONTH}}, happy birthday to you! Here's something from us to help you celebrate your special day... Outputs: Hey Mickey, it's your birthday on the 14th July, happy birthday to you! Here's something from us to help you celebrate your special day... Review Request (eg): Hi {{FNAME}}, thanks for ordering; {PRODUCTS}} We hope you're happy enough to give us a positive review! You can always check the status of this order at https://www.shop.com/account_history_info?order_id={{OID}} Outputs: Hi Mickey, thanks for ordering; 1 x Samsung Galaxy 2 x Under Siege We hope you're happy enough to give us a positive review! You can always check the status of this order at https://www.shop.com/account_history_info?order_id=23 I'm just now cleaning up the code to ready it for live testing...
  10. burt

    Email queuing system

    Easiest option would probably be; put both languages in the same email... but yeah, try it when it comes
  11. burt

    Email queuing system

    The checkout in osc is default_language only so far as I recall, but there is nothing to stop shopowner from writing a multilingual outgoing email...
  12. burt

    Email queuing system

    Idiot I forgot one important part of the whole thing: order_id Without that order_id as an available {{OID}}, shopowner cannot direct the customer to (eg account_history_info.php?order_id=X - which would obviously be very useful. I don't have time today (out most of the day) but will get that into the system later on tonight ready for testing. And then I'll get the full system out to a couple of shopowners for real-life testing, and dependant on the result of that...out into the wild.
  13. Would it be of interest to the shopowner community if public feedback was given on addon support threads? Feedback could be from other shopowners and from coders. I'm thinking things like: This addon uses incorrect HTML This addon is not multilingual This addon should use addBlock not addContent This addon is excellent in all regards etcetc
  14. burt

    Email queuing system

    My system is more geared towards what the customer does (or does not do). So all the emails are inserted/deleted depending on customer action. The only thing admin can do is insert emails into the Queue or delete emails from the Queue from the admin side "view queue" page. There isn't an automatic mechanism for (eg); admin updates order to "shipped" => email does not get added to queue It's 99% about the shop-side, customers focus - which is I think quite different from the system you have? Would it be be of more use (to the original topic) if I split out this development and chit chat into it's own thread. I kinda hijacked your thread, sorry 😕
  15. burt

    Email queuing system

    28d is still available to all.
  16. burt

    Email queuing system

    It'll go out to 28d people soon 👍
  17. burt

    Email queuing system

    A couple more hours spent on it this morning, now it's really nice. There's just one piece of code I'm not super happy with, but I don't think I can do anything about it due to osCommerces architecture - I'll have a think on it today. This is a -potential- gamechanger addon I think.
  18. burt

    Email queuing system

    Great, it's looking good... Burty signed up today but didn't complete a checkout - Email will go out in 5 days asking if there was a problem *** - Email will go out 31 July with birthday wishes (21 days prior to his birthday) Dan signed up today and gave his birthday, and completed a checkout - Email will go out 27 April wishing him a happy birthday (approx 3 weeks prior to birthday) - Email will go out 10th May (60 days) asking for a review - Email will go out 10th March 2020 asking why he hasn't ordered for a year *** Rene completed a checkout today - Email will go out 10th May (60 days) asking for a review - Email will go out 10th March 2020 asking why he hasn't ordered for a year *** Steve completed a checkout today - Email will go out 10th May (60 days) asking for a review - Email will go out 10th March 2020 asking why he hasn't ordered for a year *** *** - these emails get cancelled depending on customer interaction. As an example, let us say that Burty logs in 2 days from now (13 March)...and completes a checkout...what happens: no_checkout is cancelled as he has now checked out request_review goes out in 60 days (so May 12th or so) from the date of sale winback will go out about 13th March 2020 asking why he hasn't bought anything for a year (remembering that this would be cancelled if he did log in inside that year) Pretty cool little system ? I'm pleased with how it's turned out. You may have noticed I made a "no_checkout" slug - it took less than two minutes, no core code changes - all plugged into the system automatically. BOOM! That is the future of osCommerce.
  19. burt

    Email queuing system

    Yes pls Dan - the more testers the better.
  20. burt

    Email queuing system

    @René H4 60 days (choosable by shopowner) from now send a review request 365 days (choosable by shopowner) from now send a "haven't seen you for a year" winback email If in the meantime, you were to buy something (say in 6 months)...that winback would be deleted and a new one a year from the next sale would be put in its place.
  21. burt

    Email queuing system

    A bit more refinement has gotten this to NO CORE CODE CHANGES https://template.me.uk/28d2019/ Please have a test? Anyone who has already create a account ... would just need to perform a checkout, or create a whole new account (with DOB) and perform a checkout. I can then screenshot the email queue to explain what emails would be incoming to you in the future... You won't get any emails as the closest one (on a new order) would be at least 15 days away - and I will delete the tests well before then. Hope that makes sense...
  22. burt

    Email queuing system

    I've installed this system on the 28d Demo - and, so far so good. I (as admin) manually inserted an email in the Queue - set for a few days ago - so it would fire off immediately. Here's the Slug: Here's the received Email: TL:DR; The whole system is working as intended! I'll test it a bit more and then get a couple of shopowner to raise their hands for testing...
  23. burt

    Email queuing system

    Unfortunately not. It's a difficult thing to do (in osCommerce).
  24. burt

    Email queuing system

    And here's the Slug page, aka email templates... So, just one more thing to do...send out emails at about the right time, and make sure the emails use the merge_vars as shown (anyone who runs Mandrill will understand merge_vars). But in this relatively simple system, assuming an email was going out to Donald Duck, the word {{FNAME}} would be replaced with "Donald". So, next step is to tie it all together and see if the concept works...
  25. burt

    Email queuing system

    So far so good - the whole system is up and running with just one core code change. I went down the 1 core code change route to save multiple code changes in the future...it'll make sense once you see it... Here's the admin side for viewing the email queue. In here you can; add emails to queue delete emails from queue edit email (eg change outgoing date etc) Date = date email will be sent. Name/Email = to whom. Slug = what is going to be sent to them. If you put two and two together, you're probably thinking "slug"?? I now need to create an admin page where shopowner can set up email templates, so a "slug" would be something like: winback Title: New stuff at XYZ shop Text: Hey {{NAME}}, we haven't seen you for a long time - we have hundreds of new products for you to look at! Here's a voucher for 10% off. Love from XYZ Shop. Kthxbye.
×