ectmechanic1

I am implementing a web page where users can enter URLs of pages on external sites. My page includes an <iframe> element where the URL is previewed. Unfortunately, quite a few URLs have javascript included that checks whether the page is being displayed in the topmost frame and if not makes sure it is. Here is an example of such code (obviously there are lots of slight variations): <script language="JavaScript"><!-- if (self != top) { if (document.images) top.location.replace(window.location.href); else top.location.href = window.location.href; } //--></script> The effect of this is when the user chooses a URL like this and it is previewed in my <iframe>, the JavaScript runs and the URL is now 'previewed' in the whole web page . Does anyone know how to stop this happening - one that works for all possible bits of JavaScript that do this not just the exact piece above. I've spent ages on Google looking for a solution but can only find ones (or promises of solutions) where you have to sign up for a free trial and give payment details. thanks in advance to anyone who has any ideas ectmechanic1

Cabbage, You know that static variables hold their value when they're not in execution. So the piece of code below runs only once - when the function and it's static variable are defined and before the function is ever called. static $a = 0; If you wanted to change the value of $a within the function you would write this: $a = 'new value'; You are changing the value of $a already within your function with this line: $a++; This will just increment $a by 1, of course. The disadvantage of OO scripts is that scripts written for PHP5 sometimes won't work with PHP4 (e.g. PHP4 doesn't do static variables within classes). But it's really a question of taste, if the linear scripting works well enough then you may as well keep it. OO scripts are most useful if you are going to be creating some functionality that will be reused for several different applications.

Since my last post I've used Google Checkout a few times to receive payments for invoices. I've only used the manual 'generate invoice' option rather than the cart but here are my comments. This is it's good point: It's a lot cheaper than PayPal in terms of transaction fees. These are the not-so-good points: Unlike with PayPal customers have to start their own Google Checkout account before they can make any payments. You can only chage in £'s The management interface screens where you can see all the payments going through is not very well developed compared to other Google services. If you are going to be dealing with a lot of transactions you might have trouble keeping track of your money. In fact you can't see unpaid invoices at all. My guess is that once Google improve the management interface and allow you deal in multiple currencies they will put the fees up ectmechanic1

Each item in the feed can include a permalink or just an ordinary link so that people can click through to reach the full page on the site. So if you wanted to force people to go to your site you could just put an introductory bit in the feed item and if people were interested they could click through to a full article.

Is the URL being displayed in the iframe in a different domain than the URL of the surrounding webpage? If so you are going to run up against JavaScript security. JavaScript is designed to prevent code from a page in one domain knowing what the user is doing on a page from another domain. This is to prevent malicious code things like finding out what password you are entering for another site. This security feature is core part of JavaScript and so you won't find any workarounds. If you are the creater of the page being displayed in the iframe you could maybe adapt that page so that when the user pressed a button in that page some JavaScript ran which sent a message to domain of the main page.

If your issue is "How do I get my Shopping Cart to connect to the database?" then you need to look at your shopping cart's documentation where it will tell you how to set up your database settings. As well as database name, user name and database password you will have to supply database host. For this last one try entering localhost and it should work. One thing to watch out for is that the database user name and password will be different from the user name and password you use for FTP access. In fact the database password should definitely be different for security reasons. If you are trying to write your own shopping cart software then it would be a good idea to give up and try something simpler because as a previous poster said shopping carts are very complicated.

mehdi, It is impossible to tell from your screenshot what eCommerce system the site is using. This is because most ecommerce systems (osCommerce, ecommerce templates etc.) are templates and users then customise them with their own graphics and can change the layout. If someone is familiar with a cart system then they can often spot a site that uses it even when that site is very customised. The clues are in the URLs, the layout, how the checkout works, and the bugs. Looking at the screenshot you supplied - if you know it is a small company then you could guess that they must have based it on an ecommerce system as it would be too much work for them to write their own.

I tried out some of PHP's OO features but there were 2 limitations: PHP OO does not compare with Java or C++ so the benefits are less likely to justify the extra work. Some of features (like static variables) only work with PHP5 and NOT PHP4. This is a problem since a lot of mature sites (ones that make money) still use PHP4. Other programmers with no experience of a language like Java are completely confused. OO = Object Oriented This helps with organising code in large programming projects and should mean less bugs. You create classes which can have methods and varibles. Then you create objecs which are instances of a class. Then your code can look like this: $myaccount = new Account('John Smith'); $myaccount->setBalance(1000000); $myaccount->pay('PayPal', 'me@me.com', 14000); $cash_left = $myaccount->balance;

It looks as if things are going wrong at the 3rd line: if(is_uploaded_file($_FILES['logo']['tmp_name'])){ So you should check: Did you the file control in the form the attribute name="logo"? Did you give the form the attribute: enctype="multipart/form-data"? Did you put a hidden file-size value into the form. It would look like this: <input type="hidden" name="MAX_FILE_SIZE" value="100000000"> (put in value that's big enough for the size of your image in bits) You might also have to change your server settings to allow the upload of large image files. Try things out on a very small icon-sized image first. If you get that to work and hit problems with 5MB photographs you will know that the issues are size related.

You only pay if people click through so no need to worry about people who ignore the ads - in fact if you write your ad clearly you might get a bit of name-recognition in a niche market. It can be good value if you only bid a small amout for each click and pick some less obvious keywords - your ad won't appear for very obvious keywords unless you make high bids for them. The trouble is that you will only get a handful of impressions a day (an impression is when your ad is displayed) and one click-through every couple of days.

Google Checkout is cheaper than PayPal (only 1.5% instead of 3.4% or 3.9%) but I believe that if you use the UK version you have to charge in £s which might be a problem for some sites.

You should only think of implementing a shopping cart as learning exercise. Shopping carts are very complex, dull systems and need large teams of developers to create and maintain. But if you are very keen and want to jump in at the deep end you could go to the websites of payment providers like Google Checkout, PayPal, Worldpay etc.. They all have sections with guidance for developers who are creating interfaces with their payment systems. You'll find lots of documents explaining exactly how your shopping cart application should integrate with their systems.

ErisDS, You can customise WorldPay, including (I think, I haven't done it with WorldPay) supplying template pages so the payment pages look like they are part of your own site. Take a look at this link: http://www.worldpay.com/support/content.ph...sub=customising Personally I find: When I am a customer: going to a secure payment service like Worldpay is preferable to supplying my credit card details to a small web-based business who probably don't have a clue about security. When I am implementing an ecommerce site: WorldPay means less worries about security as no credit card details are stored on your site plus WorldPay keep a separate record of all transactions. The big problem with WorldPay and template pages is in a case where your client operates more than one website using the same Merchant ID. Then the payment pages have to look the same for all sites.

If your web-server has the Image Magick module installed you can use that do do things like resizing images. Although the results are not as good as you would get doing it by hand with something like Photoshop Elements. Here is a link to the website for this module: Image Magick You may need to find a book with a tutorial to give you step-by-step instructions, but you will also need to follow that link to get details of what the parameters do. There is a newer graphics package for PHP called gd (apparently) but I have never used it.

A big factor for this is Firebug being a lot more informative than IE Developer Toolbar I should think.