For some reason, the dhl intraship plugin does not seem to recognize when there are new orders. The cronjobs are running fine, but from what I could see in the code, they are always starting with intraship/shipment entities, but the corresponding table in my DB is empty, therefore the cronjobs do nothing.
How do I get the plugin to fill the table? Hopefully I could go from there and fix possible config problems.
My Magento Version is CE 1.7.0.2
I have no local overrides and no modifications in community/Dhl folder (I reinstalled and there were no changes in git)
Thanks! And sorry for the vague question, but I have no error messages whatsoever.
It appeared another module was listening to the sales_order_invoice_save_after event, creating a shipment and increasing the QtyShipped for orders right when the Invoice came in. Therefore the orders canShip() returned false when the intraship module ran the cronjob.
Related
I've posted this question on magento.stackexchange.com but got no response due to lower traffic there than here... So here it is...
I'm working on a website for a client and right before publishing the
website, I noticed that all the products went out of stock itself. So
I put them all back in stock and everything looked fine, but when I
checked back after a few hours all the products were back out of
stock.
I tried a few times to re-enter the stock quantities, re-index and
clear the cache, but I'm still having this weird issue - everything
looks fine until like 2-3 hours later everything goes out of stock.
Any suggestion what could be causing this issue?
Thanks in advance!
PS. I didn't share the code because I would have to share the code of the entire website...
Any suggestion what could be causing this issue?
Any imaginable 3rd party application or module that has access to cataloginventory model or its tables in database.
Suggestion how to debug this:
put this snippet into inventory observer
app/code/core/Mage/CatalogInventory/Model/Observer.php
somewhere at the begin of saveInventoryData method. (Or create local module and observe a save event)
Mage::log(Varien_Debug::backtrace(true, true), null, 'inventory.log');
after you reproduce the behaviour just check the log file under <doc root>/var/log/inventory.log
We just installed Magento CE 1.7 and we’ve run into some trouble.
We want to send newsletters but it doesn’t want to schedule the send events in the cron_schedule table. First i thought it was the newsletter part that didn’t work. Then we installed mailchimp extension which exports the subscriber adresses to mailchip trough cronjobs ... again the cron_schedule table remains empty.
Anybody have any idea why it remains empty ... i configured the cronjob following an online guide but since the table remains empty it can’t do anything
Anybody know my problem ?
We have recently updated a Magento site to version 1.12. Now the site wont retrieve up-sell products to product details page anymore. No custom code changes committed and no target rules specified. Still the up-sell product relations are visible in back end and in the catalog_product_link table as well. But I always get an empty result set to template\targetrule\catalog\product\list\upsell.phtml.
Anyone came across a problem like this?
Are there some other conditions that needs be satisfied in order to show up-sell products?
May by my database update scripts haven't run correctly. If so what are the tables/modules I should have a look at?
Did you run reindexing.
For product collections flat tables are used.This needs reindexing.
Also make sure you clear your cache after reiundexing.
I have spent 3 hours now trying to resolve this error when trying to re-index my catalog in the Admin.
I do not want Magento to manage my inventory, so I set it to No in the Inventory area of the admin. When I go to re-index the site, I get the error "Cannot initialize the indexer process.”
I have searched here and on Google, and the 2 or 3 mentions of it, those solutions do not work for me. And when I try to change back to have Magento manage inventory, since I cannot get it to re-index, all of my products just disappear from the public side.
The only way to get my products back is to re-import the database and start over. But then, when you try to add a product to your cart, since I do not keep my own inventory, the user gets an inventory error.
Has anyone seen this issue with 1.6 and found a solution?
i have solved my problem, after trying almost all the solutions listed on forums with no results.
What i did is, changed my DB user and assigned him all the rights. Before that the user of my DB didn't have all the rights.
Note:
This may not be the case with everyone but still it is a solution for me.
I've imported 6K categories and 16K products to magento using a custom import profile.
When I'm trying to reindex everything works except for 'Catalog URL Rewrites' that keep showing PROCESSING but never completes.
log and exceptions files don't show anything.
Is there something I can do to make the index work?
Can I just ignore this index and not use it? (I don't know what it does).
Thanks
You can sort of ignore this index if you do not care about pretty, search engine "friendly" URL's. The products will still appear in the catalog but will have their default "Zend Framework" type URL (/catalog/product/view/id/123)
My store has 150,000+ SKUs in two store views. On my development environment it took almost two weeks to complete.
The best way to determine how fast it is running is to look at the core_url_rewrite database table. It appears that the process starts at product ID 1 in store ID 1 and looks to make sure all of its URLs exist and creates the ones that do not yet exist.
For me the reason it took so long was that it had to go through my entire catalog twice to make all the URLs. One thing I did notice was that this process creates a ton of URLs that are completely unnecessary. In our store easily 90% of our products belong to a configurable product so their visibility is set to "Not Visible Individually" so they never would need to have a URL. This index creates those URLs anyways.
Hopefully this will shed some light on to how this URL works. I would keep an eye on that database table so you sorta know how far the process has come. I would also seriously consider running the reindex process for the command line. I have included a link that explains how to do this (disclosure: it's from my blog)
http://overlycaffeinated.com/2011/02/when-reindexing-in-magento-fails-use-the-command-line/
My own attempt of reindexing URL rewrites was with 10,000 products and it took me like an Hour and Half to finish up.
this link will help you do it from Command Line , which is preferable than doing it from the same Magento admin panel.
http://www.yireo.com/tutorials/magento/magento-administration/340-magento-14-cronjobs
Make sure you read the part about skipping some basic configuration when facing memory limits , this is the one i usually use.
You need catalog URL rewrites to make your catalog work properly. How long are you letting it run for? There's a really substantial amount of data to be written to it...
If you cannot make it work programmatically, it may be possible to shove the data into the table manually and force the index to feel refreshed? Caveat emptor, I have not tried this.
I was encountering the same problem, the server that I am running this on is a FreeBSD server. With the help of the sample of the above code I was able to get the issue to resolve buy running the following command in the shell.
/usr/local/bin/php /usr/local/www/magento/shell/indexer.php --reindex catalog_url
It runs very quickly and resolved my issue. I then created a cron for this to run every 6 hours on my server.
You can reindex using command line it will reduce 75% of load and your magento admin panel working as normal while reindexing.