The Solution

I trawled the net archives for a short while and couldn’t find any way of calling a refresh on the widget directly. In fact, the answer I came up with is so simple that it should have seemed obvious straight away!

I added an action to my shopping basket controller which calls a view with just the widget embedded and nothing else.  After all, the purpose of a widget is just to display it.  

In that way, I call my new “refreshBasket” action using an ajax call.  The returned data is the widget HTML which I inject back into the basket div.

In reality, this is included within the Javascript function that handles updates to the basket as follows:-

 function changeBasket(vitem) {
               qty=vitem.value;
 
               var url=vitem.attributes["url"].value+"?qty="+qty;
               jQuery.ajax({
                'url': url,
                'success': function(data){
                    basketVisible=jQuery('#shopping-cart-items').is(':visible');
                   jQuery("#shopping-cart-wrapper").html(data);
                    if (basketVisible)
                        showBasket();
                }
            });
        }

How it works

The link calling this routine is embedded within the detailed cart.  In one case this is using an input field so that users can change the quantity

<input value="2" size="1" id="item-32" url="/basket/updateQty/32" onchange="js:changeBasket(this);">

The URL for the update is created within Yii and then embedded as an HTM attribute.  This URL is then extracted in the changeBasket routine with the line starting “url=” 

This url is then used as the AJAX call.

On successful completion of the AJAX call, firstly see if the drop down detail of the basket was visible and store true/false.

Then inject the returned HTML back into the basket wrapper.

If the detailed basket was visible, then redisplay it.

This post will bring these two previous posts into reality with an example layout view.

The first factor is that your main menu line will remain as you have already defined it, probably using a cMenu class.

Your submenu is defined as a DIV element immediately after your main menu container.

You can then manage the visual integration of these two elements using CSS.

<?php
// if controller name matches current controller then this must be the active menu
function activeMenu($cid, $menuName) {
    $activeMenu=($cid==$menuName) ? array('active') : '';
    return $activeMenu;
}
?>
<div class="container" id="page">
 
	<div id="mainmenu">
		<?php  
 
                $cid=Yii::app()->controller->id;
                if (Yii::app()->user->isGuest) {
                    $menu=array (
                        	array('label'=>Yii::t('user','Login'), 'url'=>array('/site/login'), ),
				array('label'=>Yii::t('user','Register'), 'url'=>Yii::app()->getModule('user')->registrationUrl,  ),
		    );
                } else {
                    $user=Yii::app()->getModule('user')->user();
                    //var_dump($user);
                    if ($user->superuser) {
                        $menu=array (
                                array('label'=>Yii::t('user','Manage User'),'url'=>'/user/admin'),
                                array('label'=>Yii::t('user','List User'),'url'=>'/user')
                            );
                    } else {
                        $menu=array (
				array('label'=>Yii::t('user','Subscription Details'), 'url'=>array('/user/profile'),'active'=>activeMenu($cid,'profile')), 
				/** Other User menus **/
				array('label'=>Yii::t('user','Logout').' ('.$user->email.')','url'=>Yii::app()->getModule('user')->logoutUrl,'itemOptions'=>array('class'=>'right') ),
                            );
                    }
 
                }
 
                $this->widget('zii.widgets.CMenu',array(
                                    'items'=>$menu,
                                    'activateItems'=>true,
                                ));
                ?>
	</div><!-- mainmenu -->
 
        <div id="submenu">
            <?php $this->widget('SubMenu'); ?>
        </div>

 'log'=>array(
			'class'=>'CLogRouter',
			'routes'=>array(
                            array(
                                'class'=>'CWebLogRoute',
                                    // you can include more levels separated by commas
                                'levels'=>'trace, info, error, warning, vardump',
                                    // categories are those you used in the call to Yii::trace
                                'categories'=>'*',
                                // This is self-explanatory right? but also works in Chrome!
                                'showInFireBug'=>true
                            ),
                            array(
                                'class'=>'CFileLogRoute',
                                'levels'=>'trace, info, error, warning, vardump',
                            ),
                          /*  array(
                                'class'=>'CEmailLogRoute',
                                'levels'=>'error, warning',
                                'emails'=>'me@example.com',
                            ),*/
			),
		),

I use a function to create a trace log, defined in my base index.php as follows:-

function fb($what,$where='fb.somewhere'){
    $what=print_r($what,true);
     Yii::trace(CVarDumper::dumpAsString($what,10),$where);
     if ($where=='trace')
         Yii::log($what, 'info', 'application');
}

In this way, I just need to add “fb ($variable, “optional category or comment”);” in my code!

Yii extensions

I tried several email extensions from the Yii website all of which I found overly complex to setup and use.  I then remembered that I had used a simple class on a PHP website a few years previously and went back to look at how easy it would be to lift out and use in my Yii application.

It turned out to be a very compact set of 3 classes, which were well documented in the code and easy to setup.

All you need to do is copy these three classes into your models directory and then you can use them within your code as any other Yii class:

     $mail = new PHPMailer(); // defaults to using php "mail()"
     $mail->IsSendmail();
     $mail->WordWrap=70;
     $mail->AddReplyTo("someone@gmail.com","");
     $mail->SetFrom("another@gmail.com", 'Another Gmail address');
     $mail->Subject    = $subject;
     $mail->AltBody    = "To view the message, please use an HTML compatible email viewer!"; // optional, comment out and test
     if($mail->Send()) {
        echo "Message sent to $to!<br />";
        return true;
    }

Further resources:-

Software: PHPMailer - PHP email class
| Contact: via sourceforge.net support pages (also www.worxware.com) |
| Info: http://phpmailer.sourceforge.net |
| Support: http://sourceforge.net/projects/phpmailer/ |
| ------------------------------------------------------------------------- |
| Admin: Andy Prevost (project admininistrator) |
| Authors: Andy Prevost (codeworxtech)
| : Marcus Bointon (coolbru)
| Founder: Brent R. Matzelle (original founder)

In the case of an eCommerce system, this would mean that all your products are now held in the same table as your posts and pages.  One obvious advantage of this is that to search your site just became a whole lot  easier!

I’ve just finished a large upgrade to WP-eCommerce website using GetShopped’s latest 3.8 architecture with that integration into WordPress model  -  see rockwaterstudio.com.   Along with a cosmetic face-lift it makes the site far more concise, easier to navigate and also better for Search Engines (SEO).

If you think your site could  do with a face lift, giving it a breath of fresh air and perhaps better search engine visibility, then drop me a line or give me a call.

For several weeks now I have been on the holy grail, trawling through OLD wpsc/wpec documentation and scouring the interweb for the answer to the primary SEO criticism of WordPress eCommerce.  Even the latest 3.8.8 beta still does not address this very fundamental issue.

The problems lies in the organisation of products within categories.  The very structure of wpec encourages you to show the same product in more than one category.  having done so, you will then find that that one product has multiple URLs (http://your-store.com/category1/product-title and http://your-store.com/category2/product-title).

You may think that is a great idea, that you now have twice as many products as you had and Google is bound to love it! WRONG!

Google does not like duplicate content.  you now have the same page displaying in two different places and Google (and Bing) will not look kindly on that.

Moreover, if you ever want to move that product from category1 to category3 you now have a dead link that both search engines and peoples’ bookmarks might be pointing to.  Your product no longer exists at http://your-store.com/category1/product-title

The way it should work is that all you products should appear at something like: http://your-store.com/products/product-title.

Then  whether you are looking at the product in category1 or category2 – they point to the same URL.  If you then move the product from category1 to category3, the URL of the product does not change!

Firstly, I tried using .htaccess redirects which you can read about in my previous post “WPEC Products in multiple categories cause SEO duplicates“

The Hack

So, the hack to core wpec/wpsc files to get this to work is really simple but boy!, did it take me a long time to find it.

You will find a file called functions.php in plugins/wp-e-commerce/wpsc-core

Change line 1241

from: $our_permalink_structure = $wpsc_page_titles['products'] . “/%wpsc_product_category%/%postname%/”;

to:  $our_permalink_structure = $wpsc_page_titles['products'] . “/%postname%/”;

That is it!

Whilst trying to customise a bought in template and digging around in a customer’s WordPress eCommerce system, it occurred to me that there is a fundamental design flaw in the system from two perspectives.  Both have to do with the way that Products are assigned to Categories and how you navigate from a Category to a Product.

Permanent Categories

If my understanding is right, which it could easily not be, then when you assign a Product to a Category this must be a permanent assignment. Why – If you ever remove it, you may end up with an orphaned URL which Google and the rest of the world might have book-marked.

For example; say we are a book store and have divided our store into three basic categories; fiction, non-fiction and General Interest.

We receive a new book eg: (“Zen and the Art of Motorcycle Maintenance”) and decide to assign it to the non-fiction category.  Depending how we have setup our Permalinks we might end up with a URL to this book as http://www.ourbookstore.com/non-fiction/Zen-and-the-Art-of-Motorcycle-Maintenance

However, the next day we decide that we shouldn’t have put it in non-fiction but general interest.  We therefore go into WPEC and change the category assignment from non-fiction to general-interest.  Great!  It all works and now we can see the book at http://www.ourbookstore.com/general-interest/Zen-and-the-Art-of-Motorcycle-Maintenance

The day after that, we are browsing through our server logs (as we all do) and notice that someone is still trying to access the old URL of http://www.ourbookstore.com/non-fiction/Zen-and-the-Art-of-Motorcycle-Maintenance.   Further  investigation shows that during the first night Google spidered our site and caught the non-fiction URL and has not corrected it.

SEO and duplicate content

The second reason this is a fundamental flaw is from an SEO perspective.  If I assign a product to more than one category (eg: non-fiction and general-interest) then this book will have two URLs.  Whereas, you might think that is no bad thing, in fact, maybe even a good thing, Google won’t like it.  It is one of Google’s objectives to cut down on duplication on the internet.  It is even believed that they may penalise a site that is consistently producing duplicate content.

If you have hundreds or even thousands of products and each product is in 2 or more categories, then you could be penalised by Google.  Maybe you already have been!

Solution

Ideally, WPEC shouldn’t reference the product as part of the category.  The book should always be stored at, for example, http://www.ourbookstore.com/books/Zen-and-the-Art-of-Motorcycle-Maintenance.  In this way, if you move the product from A to B, the product URL itself doesn’t move.

Well, I’m not a WordPress guru.  I can find my way around OK but navigating the multiple layers of WPEC as well …

In the meantime, it dawned on me the other evening whilst walking the dogs, that we could easily correct this URL by using a technique called “URL rewriting”. By setting up some simple rules we could re-write the offending URLs so that it always appeared as if the product had a permanent URL independent of category.

Step 1; we need to setup a catch all Category.  In this case, as in my example just above, I’m going to call it books.  Now, every product I add to the system, I assign to the category books as well as to fiction, non-fiction or general-interest.  So, if I navigated to http://www.ourbookstore.com/books/ I would see every book in the store.

Step 2; we define a rule to redirect any category/product URL which isn’t  books/book-title to books/book-title.

How do we setup a rule, you may well ask.  The answer is, it depends on your experience and the size of your store.  If you are not a nerdy type and you maintain your own WPEC store, then you can use a “redirect” plugin (like this one http://urbangiraffe.com/plugins/redirection/) or if you are a serious techy you can use htaccess.

So the logic of the rule is

1. If the URL does not contain my “catch all” category (eg: “books”) then

2. and the URL contains a category followed by something else then

3. re-write the URL to my new catch-all category (books) plus whatever followed that part of the URL

Lets have a look at some examples;

/non-fiction/zen-and-the-art -> /books/zen-and-the-art

/non-fiction/zen-and-the-art/search=some-text -> /books/zen-and-the-art/search=some-text

/non-fiction -> doesn’t get re-written as there is nothing after the category name

/something-else -> doesn’t get re-written because it isn’t a category

To make this easier, WPEC preceeds all its’ URLs with a /p/ showing that this is a URL to a product or category/product

Therefore we can use this “/p/” to distinguish WPEC urls from other wordpress urls.

With htaccess we can achieve all of this with just 2 lines of code as follows:

RewriteCond %{REQUEST_URI} ^(?!/p/books).*$
# this RewriteCond is needed to stop a rewrite loop
# In other words, ignore any URL which already contains /p/books
RewriteRule ^p/(.+?)/(.*)$ /p/books/$2 [R=301,L]

On further testing, I found that there was a huge limitation in this approach.

Whereas, it will work perfectly if you have a flat category structure, as soon as you have nested categories, you can never tell whether the last branch of the URL is a product title or a category title and therefore you cannot write a rule for it …

I did finally find a way of hacking the core WPSC product permalink function to do this and now I have my products all pointing to http://www.mystore.com/p/product-permalink … you can find a short post about it here, but you will need to be happy editing core wordpress files to do this. If not, you can always ask me to do it for a small charge

Happy categorising!

(see part 1 here)

	array(
		'class'=>'CButtonColumn',
		'template'=>'{update}{add}{delete}',

The ‘template’ option enables you to name your buttons as you wish. Yii understands the basic crud names of ‘update’, ‘view’ and ‘delete’ but you can specify custom names as you wish as I have here with ‘add’.

'buttons'=>array(
	'update'=>array(
		'url'=>'$this->grid->controller->createUrl("/Extras/update", array("id"=>$data->id,"asDialog"=>1,"gridId"=>$this->grid->id))',
		'click'=>'function(){$("#cru-frame").attr("src",$(this).attr("href")); $("#cru-dialog").dialog("open");  return false;}',
		'visible'=>'($data->id===null)?false:true;'

In my code I specified

This calls createUrl to generate a URL with parameters for id, asDialog and gridId which results in a GET style url such as

I then specified an onClick function which generates a javascript function.  In an admin backend, where I do NOT have the general public, I find it much quicker and easier using iframes to serve poop-up dialogs than embedded AJAX functions.  I find you get less conflicts with jQuery libraries etc.  You can find the original article by joblo on the Yii wiki

In summary, this javascript sets the src attribute of an embedded iframe object

Then you set the object to visible

Always return false to avoid any javascript failures.

This means that the iframe object can reference a controller action which is independant of your current page.  This makes testing far easier as you can easily grab the URL and open another browser window to test this call.  In the Controller Action being called, you can use the asDialog parameter to check whether this action is being called through an iframe and use a very basic layout to render this view.

Also, in the Controller Action, you embed the javascript code to close the iframe when complete.  At the same time, you can inject any returned results into you parent frame. See this post for more details on this…

Lastly, I set the visible option to true or false depending on a value within the grid.  This particular example displays all the options you can buy with this holiday and whether the customer has selected them or not.  Therefore, using the id of the linking table as an indication of whether this item has been created or not enables or disables the ‘Add’ button

Further reading:-

http://www.yiiframework.com/wiki/106/using-cbuttoncolumn-to-customize-buttons-in-cgridview/

Problem

I’ve got an Property Rental application which also holds availability by dates for each property.  If you want to search for properties that available (or have some availability) between two dates, I wanted to add a column to the gridview which indicated this.

Solution

I already use additional attributes in my models quite often.  they are so useful for storing additional values or transformations of existing values.  This is the route that I found, thanks to Dana Luther – Web Design & Development on the Yii forums.

Now, my search function in my model is already pretty complex with some INNER joins and some OUTER joins depending on whether various fields are selected in the Advanced Search form on the CGridview.

However, a simple change to some existing code was all it needed.

My existing code was something like this:

if (!empty($this->from_date) && !empty($this->to_date)  ) {
        $ds=CDateTimeParser::parse($this->from_date,'dd/MM/yyyy');
        $from=date('Y/m/d',$ds);
        $ds=CDateTimeParser::parse($this->to_date,'dd/MM/yyyy');
        $to=date('Y/m/d',$ds);
 
        $sql.=" inner JOIN (SELECT DISTINCT property_id from availability WHERE available_dt BETWEEN '$from' AND '$to' AND availability='A') as A ON A.property_id=t.id" ;
}
if ($sql!='') $criteria->join=$sql;

And a simple change to this as follows:-

         $sql.=" INNER JOIN (SELECT a.property_id, COUNT(*) AS FreeDays FROM availability a WHERE (a.available_dt BETWEEN '$from' AND '$to' ) AND a.availability='A' GROUP BY a.property_id having count(*)>1) as p3 ON p3.property_id=t.id";
         $criteria->select = "t.*, p3.FreeDays as freedays";

Plus define the public variable at the top of the model “Public $freedays;”

The next challenge is how to convert this into a parametrised query and then merge it with the existing CDbcriteria …. any ideas?

I tried setting the headerHtmlOptions and the HtmlOptions and I could see these coming through in the HTML but found that it was the width of the input boxes in the filter row that was throwing out width of the column.

I finally found a solution that works (for me). I know this is a bit of a hack but it works!

I ended up using attribute names in CSS to determine the max-width of the input boxes as follows:

input[name="Properties[ref]"]
{
    max-width: 55px;
}

Setting the width of columns in a CGridView