Technology Blog

So we’ve recently worked on converting Debragga.com into a Magento site from a very uncommon platform called vsadmin.  It’s been absolutely stellar.  The design and everything else transferred over, so it was mainly just a back end conversion.  But we’ve seen seo rankings increase, ease of updating products and descriptions, and the availability of all the opportunities that the magento eco system has to offer.

We’ve configured everything as bundled products since everything in the warehouse is a single “part”.  Everything on the site is then broken down into a package containing the sku’s of all the parts that make up the package.  This has helped simplify the pick and pack process tremendously and allowed for quicker training and the allowance of seasonal pickers and packers to assist during busy times.

Anyway, if you haven’t had Dry Aged Beef, or Kobe Beef, I definitely suggest you head over to Debragga and get some!  Your mouth will thank you.

WHen greeted by the error message:

Attribute 'setup_version' is missing for module


This is because the attribute schema_version has changed to setup_version at some point in the M2 development cycle.

Should now be:

I’m creating the test module form the Magento 2 Development Fundamentals course from Magento and ran accross the below error:

Recoverable Error: Argument 1 passed to Training\Test\Controller\Action\Config::__construct() must be an instance of Magento\Framework\App\Action\Context

I found out that the example they gave, they omitted the constructor in the Config.php controller. So let’s add that in:


public function __construct(
\Magento\Framework\App\Action\Context $context,
\Magento\Framework\View\Result\PageFactory $resultPageFactory
) {
$this->resultPageFactory = $resultPageFactory;
parent::__construct($context);
}


Then lastly, since I already tried to run it, I had to clear out some of my var folders and then recompile:


[bessig@dev htdocs]$ sudo rm -Rf var/generation/*
[bessig@dev htdocs]$ sudo rm -Rf var/di
[bessig@dev htdocs]$ sudo rm -Rf var/cache/*
[bessig@dev htdocs]$ sudo rm -Rf var/page_cache/*
[bessig@dev htdocs]$ bin/magento setup:di:compile


Hopefully this helps someone.

Also they did not supply a routes.xml The one I used is as follows:

The page you will call using this route will be: /testing/action/config

Hopefully this saves someone some time! Let me know if your one of the people it helped!

So we had a customer call in today saying that order notification emails for their site were not going out.  They run on Magento 1.9.1 which has implemented a new email queue system for magento.  They receive about 100-1,000 orders a day, which can mean several thousand emails, since each order gets several emails post order (order confirmation, order update, order shipping/tracking number, follow up email).

So the first thing I did was place a test order on production.  I did not receive the email.  I looked in the /var/log/messages for the server and searched for my email address.  It was not in there.  I did notice other email’s in there, including the account creation email, which I almost dismissed to the client as the order email.  This email is not queued like the order emails so it immediately gets sent out.

So this was a bit scary, not seeing the email in the system /var/log/messages then I remembered about the queuing Magento has, and that it runs from cron.  I looked for a locked up cron by doing ps aux |grep cron but nothing came up.  It looked like no cron was locked.  I then remembered the client had AOE Scheduler installed.  I browsed to system->scheduler->list view.

In the table we had to select core_email_queue_send_all and click on the search button.  This limits the table view to this value.  I had something like 28 results found, but my view filter was set to show 25 at a time.  So I could not see the trouble 3 at the end.  I switched to show the view at 50 which showed me all of my results and I noticed the last item was a “RUNNING” process from several days ago.  There were a few “MISSED” processes before it.

I then selected the RUNNING row and selected “kill” from the actions window.  It then said it would kill on the next cron run.  This meant that I had to wait two minutes to check back.  I checked back and it was still there.  I then selected the row and clicked on “delete” from the action drop down and this immediately removed the row.  I waited two minutes and refreshed the page and it was now running.  I also started noticing through mailgun that the emails were sending but I didn’t get mine.  This is because the most emails magento will process in one cron is 100.  This means if you have 3,000 in queue, it will take 30 minutes to get them all out.

You may also need to do this with newsletter_send_all.