Magento – Delete Tiered Pricing

Problem: Suddenly and Without Warning, I can’t Delete Magento Tiered Pricing via API

The failing code was written agains the (what I presume is called) version 1 of the SOAP kit for Magento. The returned error is “Invalid Tier Price“.

This code doesn’t work as of, and did not work in to delete Tiered Pricing:

    "" );
/* Delete Tiered prices: */
try {
    $proxy = new SoapClient(MAGENTO_WSDL_URL);
    $sessionId = $proxy->login(USER, PASS);
    $killPrices[] = array(
        'website'           => 'all',
        'customer_group_id' => 'all',
        'qty'               => '',
        'price'             => ''
    print( "Killing tier price: "  . $sku . "\n" );
    $proxy->call($sessionId, 'product_tier_price.update',
            array($sku, $killPrices));
catch( Exception $e ) { 
    print( "Tried killing tier price for $sku: " . $e->getMessage() . "\n" );


The solution works in (what I presume is called) version 2 of the SOAP kit for Magento. I mean, I don’t even remember how I found out there is a “version 2” of this thing, I stumbled across it somewhere. Anyway, using my own trusty WSDL-Dumper Gimme Gimme Thingie, I found the version 2 counterparts for manipulating Tiered Pricing: catalogProductAttributeTierPriceInfo and catalogProductAttributeTierPriceUpdate. And here’s what I ended up to get Delete Tiered Pricing to work!

This code does delete Tiered Pricing, in and

define( 'MAGENTO_WSDL_URL_V2', "" );
/* Delete Tiered Prices using V2 API: */
try {
    $cli2 = new SoapClient(MAGENTO_WSDL_URL_V2);
    $sess2 = $cli2->login(USER, PASS);
    /* Just grabbing current info and dumping to stdout,
     * Important note: the 'sku' argument is a literal argument. It says that 
     * "value in $sku is the sku attribute for the product I'm looking for."     
    $tp = $cli2->catalogProductAttributeTierPriceInfo($sess2,$sku,'sku');
    $killPrices[] = array(
        'website'           => 'all',
        'customer_group_id' => 'all',
        'qty'               => '', 
        'price'             => ''
    /* Killing the pricing by updating with "empty tiers" (insert joke here)
     * Once again, the last argument 'sku' is a literal, describing the value
     * I'm passing in $sku as an SKU. It could be, for example a product ID.
    $rc = $cli2->catalogProductAttributeTierPriceUpdate($sess2, $sku,
                   $killPrices, 'sku' );
    /* I'm printing the value returned in $rc, though I've never seen it be
     * anything other than 1.
    echo "\t----->".$rc."<-------\n";
    /* After the kill, this should come back empty: */
    $tp2 = $cli2->catalogProductAttributeTierPriceInfo($sess2,$sku,'sku');
catch( Exception $e ) {
    print( "Tried killing tier price for $sku: " . $e->getMessage() . "\n" );
    print_r( $e ) ;

Unique Photo CVS Cheat Sheet

Prepared by: Mike West November 11, 2009.

This is really a quick shorthand for the installation on that is checked out to asweet and is mostly directed for his use there. However, this is still a pretty good down and dirty intro to Version Control, and how we're using it. The aim of this document is to prescribe the correct Workflow, and, in subsequent sections, to show CVS in action in more detail.


This workflow applies to pretty much any CVS installation of any kind – indeed any Source Control system of any flavor. It certainly applies to our Magento installations, our FACTS installations, our credit card implementations, etc. These concepts become habit, second nature. Done properly, the system does everything for you: maintains a history of changes, eliminates unnecessary backups of files, maintains accountability of Who did What When. Debugging is immeasurably simpler, because you can compare any version of a file to any other version.

This is the workflow; follow this workflow and you can never go far wrong.

  1. Check out files (already done on
  2. Work, work, work.
  3. Check for updates to your file (cvs status yourfile).
  4. Update if necessary (cvs update yourfile)
  5. Resolve conflicts if necessary (that is, go to step 2)
  6. Review changes (cvs diff yourfile)
  7. Commit changes (cvs commit yourfile)

General Concepts

The important general concepts are:

  • The Repository: Store the files and the history of a given project.

  • Working Copy: Your local version of the project

  • CVS Commands: The commands you use to check out files, commit (return to repository) and check that status of files.


We have a central Repository of "Golden Code" that is stored on and backed up every night. You can peruse that source here: CVS Repository

For example, FACTS was originally imported 4+ years ago. Any change ever made by me or Dave over the last 4 years is there, commented and documented. You can also use the command line "cvsps" in any source-control'd directory to get the history of that directory for all time. Try this on johnny5 in /u/ssi6/mods/prog/SO.src. This history of changes to those programs runs some 6,481 lines!

Working Copy

Since it's typically been only me or Dave, we've kind of adopted a lax "Working Copy" policy, but we're tightening that up now. Generally, every person has their own working copy. My working copy of magento, for example, is on at /magento. Alexander's working copy is on dar.uniquephoto.comthat's right, on our remote system.

CVS Commands

Checking Out: cvs co

This gets you a working copy of the current project. For, this has already been done.
cvs co path/to/repository/project

Checking for Updates: cvs status

While you're working, the ideal situation is everyone else is working too! This means someone might have made changes while you were making your changes. So, you can issue a cvs status against your file (or entire Working Copy). 
cvs status someFile.php
Here's a real life example. Out on, boxes.css is changed. However, cvs status tells us that the repository has changed since we got our working copy out: [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs status boxes.css
File: boxes.css         Status: Needs Merge

   Working revision: 1.8
   Repository revision: 1.13 /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)
You can safely ignore the "Sticky" stuff – we're not sophisticated enough to use that yet. (And by the time we are sophisticated enough, we'll be switched to git Source Control anyway). This tells you that boxes.css is 5 revisions ahead of your working copy! Notice that status says "Needs Merge." What do we do? We update!

Merging Changes into Your Working Copy: cvs update

OK, boxes.css has been altered since our last update. Let's update again: [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs update boxes.css
RCS file: /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
retrieving revision 1.8
retrieving revision 1.13
Merging differences between 1.8 and 1.13 into boxes.css
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in boxes.css
C boxes.css
Oh Oh. Houston, we have a problem. CVS is telling us that if found "conflicts during merge." This means that changes we have made conflict with changes someone else made, and CVS can't figure out what to do about it. Problem? Nope, not at all. All we have to do is edit boxes.css again, and look for the conflicts, which CVS conveniently marks for us with leading <<< and >>>.

What have You Changed? cvs diff

After fixing our conflicts in the update, we now set about doing the actual editing we came here to do. So, asweet makes some changes to boxes.css. What were those changes? cvs diff tells us: [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs diff boxes.css 
Index: boxes.css
RCS file: /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
retrieving revision 1.13
diff -r1.13 boxes.css
<     border:1px solid #666666;
<     font:bold 12px arial, sans-serif !important;
>     border:2px solid #666666;
>     font:bold 14px times, serif !important;

The "<" means "this was in the repository version" and the ">" means "this is the change that was made." In this case around line 94, we changed the border size, and made the font larger and serif.
It is good practice to test your changes, and thoroughly review them before you commit code back to the repository. Which is what well do next.

Committing Your Changes back to the Repository: cvs commit

You're happy with your changes. You've tested them, and you've run a diff and reviewed what you changed just once more. You're ready to commit this change to the repository. [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs commit boxes.css

An editor will come up and ask you to comment on your changes (which editor depends upon your environment. Remotely, it defaults to nano.) The comment I added here starts with an '*'. The '*' is totally superfluous, I don't know why I do that. Maybe it's for legibility on multiple changes? It's an old habit.

GNU nano 1.3.12                 File: /tmp/cvstembP3               Modified  

* Made the Add to Cart Button's font larger with a thicker border.
CVS: ———————————————————————-
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS: Committing in .
CVS: Modified Files:
CVS:    boxes.css
CVS: ———————————————————————-

Now save those comments and exit the editor, however the editor wants you to save). In nano, it's Ctrl-O, <ENTER> and then Ctrl-X.

After saving the comments, cvs will report the result of your commit:

Checking in boxes.css;
/home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v  <–  boxes.css
new revision: 1.14; previous revision: 1.13

Updating the Live Site: cvs update

Yup, that's it. Just sign in to the Live Site, go to the appropriate directory and run cvs update on the file you changed. The Live Site is simply another "Working Copy" that we all agree is only updated by CVS, and never by human hands.