Hello, is this thing on?  Many of us who have, or are in the process of launching, e-commerce sites have wondered about this at one time or another.  The most common way of finding out is to make a test purchase of $1 or less, to see if everything works.  At about 35 cents a try (in PayPal fees), most people simply consider it a start up cost.  But there is an alternative, that costs nothing to use; the PayPal Sandbox.

With the sandbox you can simulate PayPal transactions, as many times as you want, without incurring any processing fees.  Not only can you simulate actual purchases, you can test drive your e-commerce site from the purchaser’s point of view.  You can even simulate how your site will react to purchasers with varying levels of PayPal funding and verification.

Getting Started

You will first need a PayPal sandbox account.  This account is separate from any of your primary or alternate PayPal accounts.  To get an account, visit the PayPal Sandbox site and Sign Up for Access to the Sandbox Test Environment.  Usually, when selecting an e-mail address for your sandbox account, you would normally not use an e-mail address associated with your site’s domain; for security reasons.  However, if you plan to conduct end-to-end testing that involves the sending of e-mail messages to customers, you might want to use a “hard to guess” e-mail address on your site’s domain, for the sandbox account.

Once you have completed the sign up and verification process, you should be able to log into your sandbox account.  Once logged in, you are at the sandbox “Home” page.  The two sections of the sandbox you will likely use the most are “Test Accounts” and “Test Email.”

Test Accounts

Test accounts are simulations of PayPal buyers and sellers.  Each test account has access to its own (simulated) PayPal account.  To properly test your site, you need to create 1 “Seller” and at least 1 “Buyer” test account.  To create test accounts, from the “Home” page of your sandbox account, select whether to “create a preconfigured account” or “create an account manually.”  It is recommended that you use preconfigured buyer & seller accounts, and then adjust them as needed.

After your test accounts have been created, you can goto the “Test Accounts” section of the sandbox, select an account, and then click “Enter Sandbox Test Site.”  Doing so will permit you to log into the simulated PayPal accounts of each test account; where you can perform most operations associated with real buyer and seller accounts.

Test Email

Whenever the “real” PayPal system processes transactions, it sends e-mail messages to the parties (buyer & seller accounts) involved.  The test accounts you create are assigned randomly suffixed e-mail addresses; with the same domain as your sandbox account.  The “Test Email” section of the sandbox will contain all e-mail messages that PayPal would normally try sending to real buyers and sellers.

This section (of the sandbox) however, will not capture any e-mail messages that your site might send to simulated buyers.  If you create a “paypaltest@yahoo.com” sandbox account, the sandbox will assign any test accounts it creates to the “yahoo.com” domain.  Any e-mail the sandbox tries to send to “sndbox_12345_per@yahoo.com” will be captured and saved in the “Test Email” section of the sandbox.  Any messages your site tries sending to that same (simulated Yahoo) e-mail address, will be sent to Yahoo and then bounced back to the (simulated) non-existent seller account (also at Yahoo).  Eventually, after enough bounces, the message becomes “lost in the bit bucket.”

To prevent this, and to test the sending of customer e-mails, you might consider creating a “catch all” e-mail account for your site domain.  Your sandbox account could be “secretpaypaltest@mysite.com” which causes any test accounts you create to be assigned to the “mysite.com” domain.  Using the “catch all” e-mail account, you could then test whether or not your site is properly sending all the messages it should be, to the buyer.

Configuring Your Site

Most e-commerce packages (such as WP eStore) that support PayPal, also support use of the PayPal Sandbox.  To setup your site, for sandbox testing, you only need to do 2 things; enable sandbox testing and specify your sandbox generated, seller test account, e-mail address.  Look for a setting (usually a check box) in your e-commerce software that says something like “enable sandbox mode.”  In the place where you specify your regular PayPal e-mail address, insert your seller test account a-mail address.  Save the settings  Now we are ready to play!

Let’s Play!

After configuring your software, if you immediately ran off, expecting everything to work… sorry.  In order for sandbox transactions to be properly processed, you must be logged into your sandbox account.  Here’s what you need to be doing…

Open 2 browser windows, or tabs; using the same browser session.  The first window is the “Test Conductor” window, and the second is the “Test Subject” window.  In the test conductor window, log into your PayPal Sandbox account.  In the test subject window, browse on over to your e-commerce site; and make sure that you are not logged in as the administrator.

In the test subject window, proceed to perform whatever test purchases or transactions you’d like.  Use the buyer test account e-mail address for all transactions.  Any PayPal generated e-mails will show up in the “Test Email” section of the sandbox; accessible from the test conductor window.  If you are using a “catch all” e-mail address (as earlier discussed), you will be able to read any e-mail messages generated by your site, as well.

Caveats And Warnings

1. You must be logged into the sandbox, in order for test transactions to go through.
2. Anyone trying to make “real purchases” while the site is configured for sandbox testing will be disappointed.  They will be presented with the PayPal Sandbox login page, when they try to checkout.
3. Sandbox transactions are indistinguishable from real transactions.  Any sales, inventory or accounting records kept by your site will “think” that a real sale has occurred.  Remember to reset any inventory or sales records.
4. Remember to undo the sandbox configuration changes to your site.
5. If, while in sandbox mode, you setup any recurring (subscription) payments; remember to cancel them.  Otherwise months from now, when you are in non sandbox mode, your site will begin receiving invalid IPN from the sandbox; and your first reaction may be to think someone is hacking you.

About the Author: This post was written by TheAssurer who writes for Tips and Tricks HQ and helps out with plugin development.

Breakpoints

Setting a breakpoint on a line enables you to pause/resume execution of code at your will. When you put a breakpoint on a line, say line 10, the program pauses execution when it reaches line 10. Let’s see how we can do that:

Turn Firebug on and enable Console and Script views. Then visit ajaxify.com. In the Script view, choose firebug.js from the dropdown menu at the top left corner. On the sub-view at the right click on Breakpoints pane. On the left margin of Script view, you will see the line numbers appear. Now click on line 10, it will be marked by a red circle. This red circle is the breakpoint, the Breakpoint sub-view will list you have set.

Now refresh and hit the Change the Message! button. You’ll notice line 10 is highlighted, a yellow arrow appearing at the margin indicates that the script has made its way to the breakpoint. From this point you can control the flow of execution using the controls now activated at the top right corner of Script view.

• Continue This button resumes execution. The script will only pause again if and when the script reaches a breakpoint.
• Step Over This button executes the current line, including any functions that are invoked along the way, and moves to the next line.
• Step Into This button ordinarily moves to the next line, as with Step Over. However, if the debugger happens to be paused at a line that invokes a function, the script will instead jump to the first line of the function.
• Step Out This button causes the script to jump out of the current function, returning to the method from which it was called.

Firebug Debug Screenshot

Conditional Breakpoints

Sometimes you may want a set a breakpoint, but make it apply only in certain conditions. You need conditional breakpoints. Right-click on a breakpoint and you’ll see a balloon-styled dialog asking you to enter a condition. This is simply a JavaScript expression; each time the breakpoint is reached, Firebug will evaluate the expression. If—and only if—the expression is true, the breakpoint will be applied and execution will pause.

Watches

A watch is a JavaScript expression that the debugger can continuously evaluate and display the value at your request, so that you don’t have to do it manually using the alert box. The expression could be as simple as a variable, or as complex as a formula containing calls to other functions. In our previous example, click on Watch and enter counter in the text field new watch expression… As you keep clicking on the Change the Message! button the value of counter increases, and you can watch the value in the sub-view at the right.

Tip: When you type in a new watch expression, hit the tab button to get auto-suggestions for properties of objects.

Call Stack Tracing

Call stack tracing is the process which reveals the sequence of function calls, with the latest function called showing at the top and the first showing at bottom. When the debuggers is paused, you can click on the Stack sub-view to see the function call sequence. For our first example, when the program reaches the breakpoint and execution is paused, the stack trace will be like this:

It means when you clicked the button, the handler for the event handleButtonClick was called, which then called changeMessage. Thus, stack tracing can give you useful insight about program execution flaw when you stuck untangling some messy logic.

Logging function calls

Sometimes a problematic function is called so many times that you can’t break into the debugger every time. You just want to know when it’s called and what parameters were passed in. To track all calls to a function, just right click on it in the Script tab and choose “Log calls to ‘function name’”. Then hop over to the Console and watch the calls stream in.

Sometimes a problematic function is called so many times that breaking into the debugger seems like a tedious task. If you just want to know when the function is called and what parameters are passed in, you can log the calls to this function in the Console. To achieve this, right click on the function in the Script view and choose Log calls to . Then switch to Console view, execute the code and watch the stream of calls.

If you don’t know what a ‘robots.txt’ file is, then read the article titled how to control access of the web crawlers or web robots to your site.

Basically, add rules to your ‘robots.txt’ file to Disallow any spider from indexing the translated version of the pages. My ‘robots.txt’ file looks like the following Depending on your situation you might need to block more languages. Just look in the Google webmaster tools and see which languages are causing the error then add them to the Disallow rule.


User-Agent: *
# Language pages
Disallow: /ar/*
Disallow: /bg/*
Disallow: /zh-hant/*
Disallow: /ca/*
Disallow: /cs/*
Disallow: /da/*
Disallow: /de/*
Disallow: /el/*
Disallow: /es/*
Disallow: /fi/*
Disallow: /fr/*
Disallow: /he/*
Disallow: /hi/*
Disallow: /hr/*
Disallow: /id/*
Disallow: /it/*
Disallow: /iw/*
Disallow: /ja/*
Disallow: /ko/*
Disallow: /lt/*
Disallow: /lv/*
Disallow: /mr/*
Disallow: /nl/*
Disallow: /no/*
Disallow: /pl/*
Disallow: /pt-br/*
Disallow: /pt/*
Disallow: /ro/*
Disallow: /ru/*
Disallow: /sk/*
Disallow: /sl/*
Disallow: /sr/*
Disallow: /sv/*
Disallow: /tl/*
Disallow: /tr/*
Disallow: /uk/*
Disallow: /vi/*
Disallow: /zh-CN/*
Allow: /

As far as I know, Google penalizes for duplicate content. Translated version of your page is considered duplicate content so for SEO benefit it is best to use this method to block access to the translated version of a web page.

It took about two weeks for all the errors to go away from my Google webmaster tools account but the number of errors started to go down as soon as I updated my robots.txt file to block the spiders from crawling all the translated version of the site. Hope this helps.

I started getting the “Unable to create directory /wp-content/uploads/2008/12. Is its parent directory writable by the server?” error when uploading or inserting image into a WordPress post just after upgrading to WordPress 2.7. First I thought it is a directory permission related error so I tried changing the permission of my ‘upload’ directory to 777 but I was still having the same problem. After trying many things I was able to fix it using the following method.

1. Log into your WordPress Admin account.
2. Go to ‘Miscellaneous’ Settings options from the ‘Settings’ menu.
3. In the Miscellaneous Settings put wp-content/uploads in the “Store uploads in this folder” text box.
4. Save the Changes by hitting the “Save Changes” button and you are done.

Fix WordPress Image Upload Error: Video Instructions

Let me know if this method worked for you.

In your phpMyAdmin page check for the ‘create new database’ privilege. If the privilege settings looks like the example shown below then your database import following the normal method is going to fail as it will try to create a database and you don’t have permission to do that.

No privilege to create new database

You will get the following error when trying to import the database file:

#1044 – Access denied for user ‘username’@'localhost’ to database ‘database_name’

To get around this problem and to complete importing your database to your new host do the following:

1. Login to your cPanel and click on ‘MySQL Databases’.
2. Create a new database with your preferred name (I am going to use the name ‘newDB‘ for easy reference. You should have privilege to create a new database through this MySQL Database panel even though you don’t have privilege to create new database through phpMyAdmin).
3. Open the sql database file that you are using for importing (e.g. ‘localhost.sql‘) in a text editor such as notepad.
4. Search for the text “CREATE DATABASE”
5. Delete this line containing the create database command.
6. In the next line change the database name (tips_tricks in this case) to the newly created database (newDB) in step2 after the word ‘USE’.
7. Now use the import wizard from phpMyAdmin to import the database and it will use the already created database to import all the tables without any problem.

Example of the sql database file before modifying

–
– Database: `tips_tricks`
–
CREATE DATABASE `tips_tricks` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE `tips_tricks`;

Example of the sql database file after modifying

CREATE DATABASE `applewoo_applewood` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE `newDB`;

Alternatively, you could request your web hosting provider to add database creation privilege to your phpMyAdmin.

Hope this will help anyone having a similar problem. Feel free to share your thoughts by leaving comments in the comment area below.

I recently installed WordPress.com Stats Plugin on one of my sites. WordPress.com Stats provides statistics on most popular metrics about the visitors to your site. Unfortunately, for some reason the plugin wasn’t working properly. It was showing zero (0) visitors for each day (which was wrong) and all the other stat blocks like “Top posts & Pages”, “Clicks” etc were empty. I tried many things like deactivating, deleting and then reactivating after uploading a new copy of the plugin to address this issue. I even used a different API key to see if that works. None of these methods worked. It was really surprising to me as the plugin works fine on two of my other sites. Anyway, after spending a lot of time trying to fix this issue I decided to read the Frequently Asked Questions (FAQ) section and found the answer to the problem. *hint* always read the FAQ section

Here is what you have to do to address this issue if you are having a similar problem.

Insert the following line in your “footer.php” file of your template at the very bottom right before the </body> tag.

<?php wp_footer(); ?>

Example of a “footer.php” file

<div id=”footer”>
<p><a href=”<?php bloginfo(‘url’); ?>”><?php bloginfo(‘name’); ?> – Example text</a></p>
</div>
<?php wp_footer(); ?>
</body>
</html>

The reason it was working on my other sites from the start was because the themes used by default had that function call in the “footer.php” file. Hope this helps solve your WordPress.com Stats Plugin issue.

Not Acceptable
An appropriate representation of the requested resource /wp-admin/post.php could not be found on this server

I tried many fixes and nothing seemed to have helped getting rid of the issue. So I decided to reinstall WordPress (How to Uninstall and Reinstall WordPress). Even the reinstall didn’t help! Later I found out that the “Not acceptable! Error 406″ occurs due to Mod Security updates on the server. So if you are having a similar problem then you can try one of the following methods to fix it.

Solution 1

backup your ‘.htaccess’ file if you have one in the ‘wp-admin’ directory then make a ‘.htaccess’ file with the following content and upload it to ‘wp-admin’ directory.

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

You can use any text editor such as Notepad to create this file.

Solution 2

This is the solution that worked for me for my WordPress site. backup your ‘.htaccess’ file if you have one in the ‘public_html’ directory. Open the ‘.htaccess’ file with any text editor and observe the lines between the “# BEGIN WordPress” and “# END WordPress” tags. Make sure the lines look somewhat like the following. If not then update the file with the following content and upload it to the ‘public_html’ directory.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Hopefully one of these solutions help fix your “Not Acceptable” error. Good luck.

Approach 1 (Full Clean Uninstall)

1. Delete all your WordPress files and folders from the site (usually from your ‘public_html’ directory).
2. Delete the WordPress database user and table (usual through ‘cPanel’ control panel if your site has ‘cPanel’)
3. Now Install WordPress from the beginning like you did the first time and you are done (How to install WordPress).

Approach 2 (Quick Fix Uninstall)

1. Delete the WordPress database user and table.
2. Create new database user and table and update the ‘wp-config.php’ file with the new information (alternatively you can reuse the same user name and table name from previous and you won’t have to update the ‘wp-config.php’ file)
3. Run the installer (install.php) by visiting your site.

It’s always a good idea to use the ‘robots.txt’ on your site to control the access of the web robots such as google bot from coming and indexing your site when you are doing extended maintenance. You don’t want the bot to crawl and index your site when you just deleted the entire content of your site! Read the How to control access of the web crawlers or web robots to your site article to learn more.