Drupal 7.26 – 500 Internal Server Error

Drupal

Drupal

Warning.

Drupal 7.26 has made a change to the .htaccess file. In the htaccess file, the new default is to include:

  • Options +FollowSymLinks

If you update to Drupal 7.26 and receive a 500 Internal Server Error, check your server. You can check the server error log. You may find what I found, the server you are using does not support the “Options +FollowSymLinks.”

Prior to this release, this option was commented out and an alternate was used:

  • Options +SymLinksIfOwnerMatch

Whether this is a security problem or not, it appears that on some servers the option to use SymLinksIfOwnerMatch is required as opposed to +FollowSymLinks.

 

Tomato Cart Variants My Be a Showstopper for Now

Javascript, Tomato Cart

Well, I like the general concept of the cart Tomato Cart, but, at the moment you may want to avoid Tomato Cart if you need variants on a product. There appear to be a number of problems with the variant in Tomato Cart.

Today, I found a third problem with Tomato Cart variants, and maybe a fourth. On top of a few nuisance problems that are obvious as you start working with variants, this is becoming a significant problem. Other areas of Tomato Cart appear to work, but, if you need variants, you could spend a lot of time eliminating bug and it is not clear how quickly these problems will be resolved by the Tomato Cart developers.

New problems identified with Tomato Cart:

  • It is difficult to match images to variants, the variant image icons are very small and there is no label associated with them. Images that are similar can not be distinguished in the administration area of the variants. Therefore, matching variant images to variants is very tedious.
  • Variant Prices do not always display on the front-end display.
  • Magnified images for variants of products do not match the image associated with the variants. This means my fix to problem 1 would require an extension to my original fix to problem 1.
  • The Tomato Cart forum reports that there are situations where adding product values, product may vanish.
  • Sometimes, creating a variant of a product, a duplicate of the variant is created in the administration area, and though the front-end displays only one variant, that variant does not display the correct information. Deleting the duplicate variant does not help, it is recreated the next time you leave the variant screen.

While Tomato Cart has a lot of potential, and is easier to configure than many carts, the problem with variants may cause you to think twice before trying to use it.

 

 

Tomato Cart Second Variant Problem

Javascript, Tomato Cart

Tomato Cart has a second problem in the Variant area. (See the first problem here.) It is possible to accidentally delete your variant content for a product with variants. There is a fix. I will first describe the problem, then the fix.

Normal/expected scenario: In the administration area …

  1. You create a variant (ex. states: Denver, California)
  2. You create a product with the variant states.
  3. You create variations for Denver and California, filling in the values for image, cost, SKU, etc.
  4. You go in to change a value for either variant of the product (perhaps the Denver variant).
  5. You press save and continue, and the following happens:
    1. Waiting message comes up on screen
    2. Waiting message goes away indicating the save is complete, your information is displaying
    3. Moments later your variant information clears and
    4. The system reprints your updated data from the database, it looks as before the clearing of the variant data.

That is the normal scenario. Now imagine, you do step 5, pressing step and continue. Your administration area reaches step 5b, the waiting message vanishes and you think everything is done. You accidentally or intentionally hit save and continue again about 2 seconds after the waiting message vanished … before the variant information vanishes. 80-90% of the time, your variant data will be deleted. (Note, the 2 second number can change as a result of your computer or internet activity. Sometimes this can be 10 or more seconds.) You may have hit the save and continue for a number of reasons (1) You are not sure there was a save, (2) You think things are done saving, you change something and hit save, or (3) other reasons. You may loose your data.

If this problem happens to you, you can fix this problem. Go to file /admin/includes/extmodules/products/products_dialog.php … line 198. Comment out the line as follows …

// this.pnlImages.grdImages.getStore().on(‘load’, onDsImagesLoad, this);

This should solve your problem in version 1.1.8.5 Tomato Cart. Hopefully, this problem will be corrected in the next revision of Tomato Cart.

 

 

Tomato Cart variant.js Correction

Javascript, Tomato Cart

Pardon me for getting sidetracked. My last memo on Tomato Cart talked about Tomato Cart working well, but, that it needed a correction in the variants handling. I mentioned I created a fix and the answer would be in a following article, and then I got sidetracked and did not give the patch. Well, let me get around to it now.

Tomato Cart is a nice cart, but, it does have a bug in variants. When creating variants, it allows you to save prices, weights, SKU, images, etc for the variants. When your visit comes to the site, they can select the variants, and see the information change. However, when the information changes, the images do not change. Oops.

I do have a fix for the bug. It may not be the best answer that could be done by the original developers of the package, but, it will solve the problem for you short-term, until they fix the problem. The change is in the file /includes/javascript/variants.js.

The problem is on about line 139 of variants.js. 



   The following line should be commented out:

        this.changeImage(product['image']);

    Replace it with:

        // this.changeImage(product['image']);
        //

        image = product['image'] ;
        $$('.mini').each(function(link) {
            var href = link.getProperty('href');
            if (href.indexOf(image) > -1) {
                $('product_image').src = image;
                $('product_image').fade('in');
                return ;
            }
        });

For some reason, the changeImage() call is not working. But the code specified is actually the code in changeImage(). Placed inline, everything works fine.

Don’t ask me why the code does not work as it existed (I don’t know), but, it is nice to know there is a work around.

 

 

SilverStripe editor need more Tags? Fix it!

HTML5, PHP, SilverStripe

SilverStripe

If you are having the problem that SilverStripe editor is striping out tags that you would like to use, fix it.

This article explains. SilverStripe uses the TinyMCE editor. SilverStripe has set up to permit you to add content to the /mysite/_config.php file and extend the tags that are accepted by the SilverStripe editor.

In the /mysite/_config.php file, add the following statement:


  HtmlEditorConfig::get('cms')->setOption(
    'extended_valid_elements',
    'img[id|class|src|alt|title|hspace|vspace|width|height|' .
    'align|onmouseover|onmouseout|name|usemap],' .
    'iframe[id|class|src|name|width|height|title|align|allowfullscreen|' .
    'frameborder|marginwidth|marginheight|scrolling],' .
    'object[classid|codebase|width|height|data|type],' . 
    'embed[id|class|src|type|pluginspage|width|height|autoplay],' .
    'param[name|value],' .
    'map[class|name|id],' .
    'area[shape|coords|href|target|alt],' . 
    'article[id|class|name|width|style],' .
    'section[id|class|name|width|style],' .
    'aside[id|class|name|width|style],' .
    'article[id|class|name|width|style],' .
    'ol[id|class|start|type]') ;

Use the format above to extend the editor to use any tags and tag attributes that you would like available to the editor. Above you see various tags and attributes being included, including HTML5 tags and attributes. You can include just the tags and attributes you believe you’ll need to support your use of the SilverStripe editor.