1. Your custom config file has am empty line in it - delete it.
2. Set file permisisons as readable and writable for all (CHMOD 666).
Check code on the composition page. In lines of code like this:
<input type="hidden" name="config" value="magic1">
you have to put only the name of config file WITHOUT the extension or path
or URL.
<input type="hidden" name="config" value="magic1">
<input type="hidden" name="config" value="magic1.txt"><input type="hidden" name="config" value="/path/magic1.txt"><input type="hidden" name="config" value="http://server.com/path/magic1">1. You edited templates with WYSIWYG editor. As a result you may have for example such code:
<TABLE border=2 cellspacing=0 cellpadding=5 <!--@bcolor--><font
color="#800000">></font> <TABLE border=2 cellspacing=0 cellpadding=5 <!--@bcolor-->
> Solution is simple: edit templates only manually!
2. You added quotation marks to bcolor and fcolor
tags.
<TABLE border=2 cellspacing=0 cellpadding=5 "<!--@bcolor-->"
> <TABLE border=2 cellspacing=0 cellpadding=5 <!--@bcolor-->
> This has nothing to do with either browser or Platinum software. This error is a reliable indicator of invalid HTML code on your pages.
Netscape even in version 6 and all versions 4.x handles invalid HTML code more strictly than Internet Explorer does. Unclosed tags, wrong nesting of tags, even unclosed quotes could crash a browser even on a very powerful computer. While IE can render the page with 4 BODY tags, Netscape simply cannot.
Such errors can be easily detected with an HTML validator. Make it a good habit to use HTML validators - you will save yourself many hours.
Important! If you are not familiar with basics UNIX administration and are not comfortable with telnet or ssh - better delegate this task to someone experienced - e.g. your sysadmin. You can order custom maintenance work from us as well.
Find your distribution archive (typically platinum.v5.tar.gz).
Copy it to your webserver's DocumentRoot (typically htdocs or www).
Unzip and untar it (use tar xfp to save permissions).
If your server supports execution of scripts outside of cgi-bin
- you should be able to send yourself a card ASAP.
If the original program was located in cgi-bin - copy the following
files to cgi-bin: magiccard.cgi, magics.cfg,
report.cgi. That should be enough to get your cardshop running
again!
Are you really sure you did nothing to affect the performance yourself? We mean REALLY? If the answer is positive, below is a short checklist for you. It covers most common causes.
If you encounter one of the abovementioned problems - contact your sysadmin. Those are the server-related issues and not related to Platinum software functioning. If you prefer us to handle this situation - you can order server administration from us (cost is not covered by Platinum license).
If you problem is different from described above - please contact us with full description of the issue.
People DO ABUSE any internet service. Postcards including. Your website will not be an exception no matter what you do. The good news is that it happens very rarely.
Unless you use your Platinum in conjunction with some membership service where the authentication is required - there is no reliable way to check who is the real sender of the card. However membership services help to confirm identity only to some extent.
Some cardshop visitors do fake the sender's email address. It's not different from spam techniques where the message is sent from a faked or unused mailbox. It's not different from snail mail with false return address. Because snail mail is old and rules are familiar, nobody sane would blame the post office for getting such mail. Nobody sane would blame the postman that brings the tons of junk print ads and glossy catalogs nobody ever bothers to open. However when the same happens with e-mail, the blame immediately falls upon the webmaster, e-mail provider, webhost, dial-up ISP, etc.
Can you do anything about it? To an extent - yes. The simplest workaround is to edit Platinum e-mail templates and include some disclaimer either in mail header or body.
In our remotely hosted services we use such a line in mail header: Comments:
MyPostCards.com Network does not guarantee that this message was indeed originated
by <!--@email--> or <!--@SENDEREMAIL--> . Please report abuse to
abuse@mypostcards.com
Some webmasters replace the To: value in the email header with
some dedicated address associated with their domain, while putting the sender's
email to Reply-To: field only. However this usually adds more confusion,
because many email clients use To: value when replying to email
rather than Reply-To:. As a result you will be getting many misaddressed
emails that you will have to forward to the real recipient.