Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts

  • Reinoud 21:14 on 1 March 2011 Permalink | Reply
    Tags:   

    Magento: Removing mandatory validation of telephone field 

    Searching the web for ways to remove the mandatory validation of the telephone field in Magento I found quite a lot results non of which actually worked with Magento ver. 1.4.2.0 or up. The biggest problem seems to be to completely remove the validation and mandatory state of the telephone field throughout the whole Magento store. Some solutions fixed it in the checkout, some fixed the client side validation but not a single solution fixed it all.

    The final solution contains three steps which are:

    1. Remove client-side (javascript) validation

    If they not already exist within your theme copy the following files from the base/default theme to your theme:

    • template/customer/address/edit.phtml
    • template/checkout/onepage/shipping.phtml
    • template/checkout/onepage/billing.phtml

    In each of these files, look for the <input> that defines the telephone field and remove the required class from the label, remove the required-attribute class from the input and make sure to remove the *.

    2. Redefine the Mage_Customer_Model_Address_Abstract class

    Copy the file app/code/core/Mage/Customer/Model/Address/Abstract.php to app/code/local/Mage/Customer/Model/Address/Abstract.php . This ensures that upgrades will not break your modifications. Now open the file and look for the part where it validates the telephone field, it should look something like this:

    if (!Zend_Validate::is($this-&gt;getTelephone(), 'NotEmpty')) {
    $errors[] = $helper-&gt;__('Please enter the telephone number.');
    }

    You can either completely remove this part or comment it out by placing it between /* and */ .

    3. Change the Customer EAV in the database

    Except for the validation we just removed in the abstract class Magento keeps a validation definition in it’s EAV tables. In the table customer_eav_attribute look for the row with id attribute_id 30 and clear the contents of the column validation_rules. Next in the table eav_attribute loo for the row with attribute_id 30 and make sure that the value of the column is_required is 0.

    Completing the above steps will effectively clear the validation and the mandatory state of the Telephone field.

     
    • Nikolas 16:41 on 4 mei 2011 Permalink | Reply

      Hi!
      Thanks for this, I had been looking for a way to remove the requirement from the admin for a along time now after having managed to get the frontend working without phone one my own.
      It seem that the db change for “customer_eav_attribute” is not required anymore (magento v1.4.1.1), matter of fact, that table doesn’t have a “validation_rules” column. Also in the “eav_attribute” table, the telephone entry was row 29 for me, but I guess one can simply search for phone to find it.. ;)

    • Matthias Balke 21:34 on 22 mei 2011 Permalink | Reply

      Thanks for this tutorial!
      I have only one problem: there is no attribute_id 30 in my customer_eav_attribute table. How can I identify the correct row?

      Regards
      Matt

      • Nick 01:48 on 27 mei 2011 Permalink | Reply

        I am using 1.5.1.0 and found the table eav_attribute had it as attribute code 17. There was a required field that I changed from a 1 to a 0 and checkout worked great!

      • Magento Notes 10:31 on 25 augustus 2011 Permalink | Reply

        You can see app/code/core/Mage/Customer/sql/customer_setup/mysql4-data-upgrade-1.4.0.0.7-1.4.0.0.8.php or other mysql.php file
        find ‘sort_order’, and
        In datebase table ‘customer_eav_attribute’ , you can search ‘attribute_id’ by ‘sort_order’

    • Chris S. 07:03 on 12 september 2011 Permalink | Reply

      I have performed all these steps and I am still getting a pop-up that states “Please enter the telephone number.” Can someone please help me with this. I am running Magento 1.4.

  • Reinoud 14:57 on 13 February 2011 Permalink | Reply
    Tags: load-average, performance   

    The load average: A (very) short explanation 

    Every server-admin is familiar with the situation: Your servers load is flaky but you don’t see any processes eating your CPU capacity, at least not constantly. What is going on? Probably the first thing you do is Google. And yes, you will find lot’s of articles explaining you that what the number means. They will all tell you that it represents the average number of processes in the run-queue over a certain period of time.

    You will learn that the health of the number is determined by the number of cores in your system. For every core the load should be 1 or lower in order to considered to be healthy. So when you have a quad-core processor with a load of 3 that should not necessarily pose to be a problem. I am explicitly putting in the word necessarily in the previous sentence because this is where many articles make a mistake. Many resources on the web tell you there is nothing to worry about as long as your load average is lower then the number of cores in your server. I oppose to this statement.

    As you might know processes have a number of different states which they can be in. One of those states is IO/WAIT. This means that the proces is waiting for access to an IO-device (for example the harddrive) . During this state the proces is considered to be in-proces thus being in the run-queue and therefore representing 1 in the load average of your server. As you can see, in this situation the number of cores in the server is completely irrelevant because even a load of 2 can mean your quad-core server is slowing down because of the lack of speed in it’s IO-device(s).

    The previous example can be recognized when the output of the command top is being watched. When you see a high load but low CPU usage you can almost certainly say that IO is causing the number of processes in the run-queue to be high.

     
  • Reinoud 19:33 on 8 February 2011 Permalink | Reply
    Tags: heartbeat   

    Heartbeat 2.x not wanting to standby 

    When you are trying to use the script /var/lib/heartbeat/hb_standby or the script var/lib/heartbeat/hb_takeover you might experience that nothing is happening. In that case you are likely to see the following message in your log (which probably is /var/log/messages) : info: Standby mode only implemented when nice_failback on .

    I know what you are thinking, just add nice_failback on to your /etc/ha.d/ha.cf configuration file and everything will be jolly good. Please go ahead, you will notice this doesn’t solve the problem. This is because of the fact that the authors of heartbeat changed the configuration parameter but failed to change the log-message. The correct addition to your /etc/ha.d/ha.cf is: auto_failback off. Just to be sure everything keeps working I would recommend to leave the nice_failback on line in place in case you might ever down grade to a version of heartbeat that is pre 2.x .

    Above information was found on the linux-ha mailing-list

     
  • Reinoud 23:00 on 2 February 2011 Permalink | Reply
    Tags:   

    Moving WordPress to a different domain 

    This is a quick not on how to move your WordPress site to a different domain. Usually this is no a task performed often, however as a developer you will have the need to do so on a regular bases when publishing a site.

    This post is very quick writeup on how to do so. First step, obviously: fix the settings in wp-config.php . Next run the following queries:

    UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com') WHERE option_name = 'home' OR option_name = 'siteurl';

    UPDATE wp_posts SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');

    UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');

    That should do the trick. Off course change new-domain.com and old-domain.com to the appropriate values.

     
  • Reinoud 19:37 on 27 January 2011 Permalink | Reply
    Tags: centos, installation   

    CentOS installation on large drives 

    This post is more a note to myself then it is a blog post. That is not a problem because in fact this whole blog is based on that very principal. Today, I was installing CentOS 5.5 onto a particularly large volume and I encountered some errors during the creation of the partition scheme concerning the placement of the /boot patition.

    It seems to be that the version of Grub that is embedded into CentOS 5.5 does not have support for booting from a volume larger then 2 TB. Having encountered this problem before with CentOS 5.4 I was struggling to remember the solution. After unsuccessfully messing around with some commonly mentioned results I gave up.

    The most easy solution to this problem: Create separate, smaller, volume for your /boot partition in the configuration of you storage controller. Yes, I know that this solution is only applicable to you who have RAID controller available in their machine. But common, every server should!

     
  • Reinoud 23:15 on 25 January 2011 Permalink | Reply
    Tags: downloader, , pear, upgrade   

    Problems with Magento’s PEAR 

    Trying to install some extensions today on a Magento 1.4.1.0 installation I experienced the following error using Magento Connect:

    pear/Console_Getopt requires PEAR Installer (version >= 1.9.1), installed version is 1.7.1

    If you experience errors similar errors while using Magento Connect or Magento’s ./pear script try upgrading your PEAR installation using PEAR. Login in via SSH to the server running your Magento installation. Change your working-directory  to the root of the Magento installation and run the following two commands:

    ./pear channel-update pear.php.net
    ./pear upgrade --force PEAR

    Doing that should upgrade your PEAR installation to the latest version. After that you should be able to install extensions using Magento connect as always.

     
  • Reinoud 19:13 on 21 January 2011 Permalink | Reply
    Tags: cacti   

    Cacti graph exportation 

    I am a enthusiast user of Cacti because it gives me a good insight in the health and functioning of my servers. Aside from that it’s a great tool to discover the cause of a problem when an incident occurs. We are all familiar with the extreme flexibility of Cacti and it’s data and graph templates but today I discovered a feature which I hadn’t seen before.

    The Cacti is the graph exportation feature to be precise. It gives you the opportunity to export all or a subset of your graphs periodically using various methods. It can export your graphs via FTP, SFTP or locally on the server that is running your Cacti daemon. Of course you can specify authentication and path information for your export but even better you can control a lot more! You can arrange everything from the timing of the exports until the size of the exported graphs.

    Possible applications of this feature are easy to imagine for example automatic offsite access to your graphs for when your Cacti server becomes unreachable and you need to backtrack the problem. Another application can be the providing of authentication free access to your graph tree for example to your internal network.

    You can find the graph exportation settings when logging into your Cacti administration panel using an account with enough rights to administer settings on your Cacti installation. After logging in you navigate to the console tab, from the left menu choose Settings under the section Configuration. On the page that appears select the tab Graph Export.

    Edit:

    Be careful with the export interval you choose. Cacti has several options to create a timing scheme, for example hourly, daily or per poller-run. Be aware of the fact that when you have large number of graphs the exportation can be quite a burden on the load of your servers I/O!

     
  • Reinoud 22:55 on 20 January 2011 Permalink | Reply  

    Continuing in English 

    Although much hasn’t yet been written on this blog I hereby officially announce that future writings on this blog will be in English.

    Choosing English as a language for this blog has two primary reasons. By far the most important is that computers are English. That’s an odd sentence but it’s true. Everything that surrounds computers is named English. Abbreviations, hardware, programming functions and language constructors but most importantly communication! As all the previous and even more is in English it seems silly to write in Dutch. When writing in Dutch over and over again there is a doubt in my mind whether or not to translate a certain word or not. Sometimes you do and it makes a sentence seem ugly, sometimes you don’t and it makes your whole post seem inconsistent.

    Except for the translational problems there is the audience. Since my primary subject of writing will be day to day handy things I encounter during my work it is useful information for the whole world. Not just the (very tiny) Dutch speaking part.

    So, English it will be. If you don’t like it: Translate!

     
  • Reinoud 19:26 on 7 September 2010 Permalink | Reply
    Tags: MySQL   

    MySQL en threads die hangen op end-state 

    Dat MySQL zich soms eigenaardig gedraagt is geen verassing. De database server geniet als gevolg van zijn brede inzet blijkbaar een onuitputtelijk respect van de ‘community’ en lijkt weinig te lijden te hebben onder steeds serieuzer worden prestatie- en schaalbaarheid-problematiek.

    Soms lijkt het alsof de MySQL het niet voor elkaar krijgt om volwassen te worden, iets dat misschien veranderd nu moeder bedrijf Sun is ingelijfd door Oracle. Een onderbouwing voor deze stelling blijkt uit een probleem waarmee ik en een aantal van mijn collegae de afgelopen weken mee hebben geworsteld.

    De MySQL server waar de problemen in kwestie zich voor deden wordt intensief belast en gebruikt maar is hiervoor hadwarematig ook ter degen uitgerust. De server beschikt bijvoorbeeld over 16 GB geheugen, verschillende processors en zeer snelle SSD schijven.

    Na enkele maanden zonder problemen in productie te hebben gedraaid begon de server in kwestie kuren te vertonen. De log-gegevens en analytische statistieken van de server vertoonde geen afwijkingen. De load was stabiel net zoals het geheugen gebruik en I/O gebruik. Na een diepere analyse kwam naar voren dat er threads bleven steken op de state ‘end’. De threads in kwestie waren altijd bezig met simpele UPDATE en INSERT queries op een variatie aan tabellen en databases. Echter zodra een thread in de state ‘end’ kwam kregen alle  andere threads die bewerkingen of selecties op tabellen en databases uitvoerden de status ‘locked’ . Gezien de intensieve belasting van de server zorgde dit er voor dat binnen een korte periode alle threads bezet waren, allen met de status ‘locked’.

    Het zoeken van de oorzaak in zo’n geval is relatief complex aangezien het vaststellen van een eenduidige oorzaak niet voor de hand licht gezien de wisselende databases en tabellen waarop de problemen zich voordoen. Na het door lezen van de MySQL documentatie met betrekking tot General Thread States werd het in ieder geval duidelijker waarmee een thread bezig was tijdens de ‘end’ state.

    Gezien het feit dat de server in kwestie een master servers in een replicatie proces sprong de activiteit ‘writing to binary log’ in het bijzonder in het oog. Was er dan toch een mogelijk probleem met de configuratie en / of opstelling van de SSD schijven? I/O prestaties waren echter dik in orde, daarbij wanneer een thread hing op end state was er geen enkele I/O activiteit waar te nemen. Misschien zat het dan toch in de cache van de schijven of  RAID Controller?

    Cache was inderdaad de oorzaak van het probleem, echter niet de cache waar we in eerste instantie aan dachten. Een tweede activiteit die MySQL uitvoert gedurende de end-state van een thread is het bijwerken van de query-cache. Als gevolg van zeer diepgaande technische problemen, hier uitgelegd door Lutz Euler, heeft MySQL last van het bijhouden van (zeer) grote query-caches. Na het verkleinen van de query-cache van 4 GB naar 512 MB is het probleem als sneeuw voor de zon verdwenen. Meer achtergrond informatie vind je hier.

    Ondanks dat de melding van de bug door de MySQL developers is gesloten doet het probleem zich in de meest recente versie nog steeds voor. Opmerkelijk want in een omgeving die veel van een server vraagt kan een degelijke query-cache het verschil maken!

     
  • Reinoud 19:54 on 5 September 2010 Permalink | Reply
    Tags: , iPhone,   

    En ook hallo vanaf een iPhone 

    Misschien minder bekend, maar daardoor niet onhandig is de iPhone App voor WordPress.

    Bekend of niet, deze post is geschreven vanaf een iPhone met de officiële WordPress App.

    Vooral handig zijn de geo-tag en de foto die ik heb toegevoegd aan deze post. Dit laat zien waarom juist blogging op mobiele apparaten bijdraagt aan een meer dynamisch internet.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel