Well....neither. The Native mobile app uses the module Mage_XmlConnect to get the needed data. It makes calls to the controllers in this module.
A bit off topic:
(almost) all the controllers inherit Mage_XmlConnect_Controller_Action so (almost) all calls pass through this action Mage_XmlConnect_Controller_Action::preDispatch().
Most of the actions just load the layout and display it, so if you want to know how some data is rendered look in the blocks of this module.
A big thank you to the team at ParadoxLabs who helped figure out this issue. I thought I would pass the solution to my problem along incase anyone else should have similar issues.
When we first noticed this issue a few months ago we were updating the categories description.
After examining the database, logs, extensions, etc., we started trying various actions in an attempt to trigger the bug (all this was done on a staging site). We observed that only a single category was losing products.
Predictably, saving the 'Fabrics' category (the category that was losing the products) caused exactly the data loss we saw on the live site. Prior to saving there were ~2800 products assigned to the category. We added a word to the category description, clicked the 'Category Products' tab, then saved. After a long load, there were precisely 1001 products assigned to the category. Saving the category again through the same process was very quick and resulted in no further data loss.
Looking at the Magento logs after that, we found this error: "Warning: parse_str(): Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in /app/code/core/Mage/Adminhtml/controllers/Catalog/CategoryController.php on line 310"
Seeing that the max input limit on our server is 1000 and there were 1001 products left after saving, that seems like too much of a coincidence to be ... coincidence.
We've since increased the php 'max_input_vars' value to 5000 or more, which fixed the error.
Thanks to everyone who took the time to help with this!
Best Answer
I assume you are talking about the "Print" button in the admin order view page.
That has no template, it uses
Zend_Pdfto generate the pdf file.The action that handles this is
Fooman_EmailAttachments_Admin_OrderController::printAction()and the method that generates the PDF isFooman_EmailAttachments_Model_Order_Pdf_Order::getPdf.