Skip to content

Instantly share code, notes, and snippets.

@kalenjordan
kalenjordan / emoji.csv
Created Nov 15, 2015
emoji.csv that can be used in php apps
View emoji.csv
😀 grinning face
😁 grinning face with smiling eyes
😂 face with tears of joy
😃 smiling face with open mouth
😄 smiling face with open mouth and smiling eyes
😅 smiling face with open mouth and cold sweat
😆 smiling face with open mouth and tightly-closed eyes
😉 winking face
😊 smiling face with smiling eyes
😋 face savouring delicious food
View web-crons.md

I've been thinking about whether it might be easier to use a separate cron file for some of my extension-specific crons and access it over the web, so that I could control the cron schedule on my end without the customer having to worry about configuring it.

I know that running crons over HTTP is generally a bad idea, but I'm just trying to think through the pros and cons.

The main con to having Magento handle this is that many people seem to be running a 5 minute cron, even post-email-queueing, which I don't quite understand. But it is what it is. So now, all of a sudden, in order to enable a feature (order confirmation emails), they're having to go in and update their cron schedule. From a usability point of view, that's quite a bit deeper under the hood than I ever want a customer to have to go in order to enable a feature. If everyone was already running a 1 minute cron, this would make things a lot more seamless, but that just doesn't seem to be the case currently.

Also, I'm concerned that in some

View custom-social-media-markup.html.twig
<table class="custom-social-footer" cellspacing="0" cellpadding="0"><tr>
<td class='social-icon-wrapper'>
<table class="social-icon facebook" cellspacing="0" cellpadding="0"><tr><td>
<a href="https://facebook.com/{{ settings.facebook_handle }}">
<img border="0" src="{{ facebook_image_url }}">
</a>
</td></tr></table>
</td>
<td class='social-icon-wrapper'>
<table class="social-icon instagram" cellspacing="0" cellpadding="0"><tr><td>
View image-fetch-observer-config.xml
<global>
<events>
<kj_magemail_product_image_fetch_after>
<observers>
<namespace_kj_magemail_product_image_fetch_after>
<class>KJ_MageMail_Model_Observer</class>
<method>productImageFetchAfter</method>
</namespace_kj_magemail_product_image_fetch_after>
</observers>
</kj_magemail_product_image_fetch_after>
View Observer.php
<?php
/**
* @param $observer Varien_Event_Observer
*/
public function productImageFetchAfter($observer)
{
/** @var Varien_Object $data */
$data = $observer->getData('data');
View note.md

Few things resonated with me about the article. I was never one of those "solopreneur on the beach" types anyways. But I think I did glamorize a little bit the benefits of being a successful one man show. Don't get me wrong, I do think it's a great gig, but I've been seeing a need for being part of a team growing in myself personally over time.

That's not to say everyone will feel like that. Certainly there are probably some people that will be perfectly content to work solo for their entire lives. And I may be one of them - jury is still out on that.

But I have been feeling more of a need to be part of a team over the past 2 or so years that I've been going solo.

Also the idea of working on bigger problems is something I've been thinking about more. I think earlier on I was more interested in working on manageable problems that wouldn't have a lot of complications and could still be reasonably profitable. I still think that's a great way to start and again a great way to live.

But I've also been

View magemail-exit-modal.html
<div data-remodal-id="mm-exit-modal" id="mm-exit-modal" style="display: none;">
<h1>(Custom) Before you leave...</h1>
<div class="cart-contents-wrapper">
<p class="loading">Loading...</p>
<div class="cart-contents hidden" style="display: none;">
<div class="item item-template" style="display: none;">
<div class="image-wrapper">
<img src="">
</div>
<div class="name-wrapper">
View magemail-unsubscribe-curl.sh
curl --data "api_key=aeb434592f1c0b8352448a54ddbe9db7&email=test@example.com" https://magemail.co/app/api/unsubscribe
View better-visitor-log-abandonment.sql
SELECT
l.email as 'Email'
, MAX(l.created_at) as 'Last Viewed'
, group_concat(product_name.value) as 'Products'
, IFNULL(customer_firstname.value, 'Guest') as 'Customer Name'
FROM kj_bettervisitorlog_log AS l
LEFT JOIN sales_flat_order AS o ON o.customer_email = l.email AND o.created_at > l.created_at
LEFT JOIN customer_entity AS customer ON customer.email = l.email
LEFT JOIN customer_entity_varchar AS customer_firstname ON customer_firstname.attribute_id = 5
AND customer_firstname.entity_id = customer.entity_id
@kalenjordan
kalenjordan / safer-magento-registration-emails.md
Created Mar 26, 2015
Safer Magento Registration Emails
View safer-magento-registration-emails.md

Safer Magento Registration Emails

This is a little idea for a module maybe for a hackathon or something. Magento includes passwords in plain text in registration emails by default. In some cases you can just suppress the password, but in other cases you can't - for example if you have customer service reps creating accounts over the phone that need to generate password and send them to customers.

So - how about integrating with readthenburn.com to send email passwords, or perhaps generating temporary password that expire after a day or two, requiring them to use the forgot password if they didn't login by that time.