thehippy

You'll have to install/load the GD extension, install the PEAR package manager, install the Image_Graph package and its dependencies. Installing PEAR Installing PEAR packages Image_Graph tutorial

PHPUnit does code coverage analysis Some other tools you might want to check out PHP_CodeSniffer - for coding standards compliance phpUnderControl - for continuous integration. ooo pretty graphs!

Haven't used it myself but there's a ffmpeg extension, looks like its only meant for a *nix OS though. Vimeo uses it so even though its still marked as experimental it can't be very unstable.

Was PNG support built into the extension? There's a note in the imagecopyresampled() about images with large palette sizes (255+1) in which you may want to use imagecreatetruecolor() in that instance.

If their sole basis is that you have too much outgoing mail, that's BS. What's more likely is that their spam filters are picking it up for other reasons. Personally, I'd request the spam filter score from the particular email/spam filtering solution your ISP is using. SpamAssassin is pretty much the de-facto standard in spam filtering, so if you can pass its filtering process you should be good. There are a few spam assassin score checker's online, in which you email an address and it will evaluate the email and give you a summary. This might be a bit precarious in your current situation though. From Spam Assassin's wiki Some Tips for Legitimate Senders to Avoid False Positives You might also want to check into DomainKeys for your email server. You could also try GPG/PGP signing your emails (with PEAR's Crypt_RSA perhaps), though I'm not sure if this has any impact spam filter weighing.

Line: 51 /**#@+ * Encoding type constants */ const ENCTYPE_URLENCODED = 'application/x-www-form-urlencoded'; const ENCTYPE_MULTIPART = 'multipart/form-data'; /**#@-*/ Line: 786 /** * Set encoding type * * @param string $value * @return Zend_Form */ public function setEnctype($value) { $this->setAttrib('enctype', $value); return $this; } /** * Get encoding type * * @return string */ public function getEnctype() { if (null === ($enctype = $this->getAttrib('enctype'))) { $enctype = self::ENCTYPE_URLENCODED; $this->setAttrib('enctype', $enctype); } return $this->getAttrib('enctype'); } As you can see, you may actually be removing the attribute, but as soon as getEnctype() is accessed to write the element the attribute is being overridden. To remove the 'enctype' attribute just for the sake of removing it doesn't make much sense, it's better to explicitly set it so you and the browser have a better chance of getting data back in an expected format. I would argue that the default behaviour is preferred in this case .

table books ----------- id eng_title eng_synopsis pub_date_begin pub_date_end publisher_id FK | | | | | | | | table titles ------------ id lang_id FK title | | | | | | | | table staff ----------- id family_name given_name date_birth date_death | | | | | | | | table publishers ---------------- id name market_symbol country FK | | | | | | | | table staff ----- id staff_id role FK book_id FK *omitted some tables, obvious what they contain. This is a simplified version of how I've broken down my data as of now. All of these tables are used in a simple book listing. If a user wanted to submit the correct spelling of the books' cover artist's last name and the books' title in German, how do I track that as a single update so a moderator can approve or revoke the update? Should I even hope that what I want is possible? I think what I've thought up is too complicated for my dataset. This is giving me a headache. I'll just have to have a suggestions box link per book and have a moderator manually add the data themselves; just so I can move on from this for now Buyocat, if I understand how you advise to do it, I'll need a table for every field that can be updated by users. Your idea works for your example.

I thought I would look into wiki's for perhaps some insight into versioned content. I looked at mediawiki and tikiwiki. They both save the entire entry at each new revision; any kind of diff'ing is done at runtime and there's lots and lots of caching going on. With wiki's each pages' content is isolated to a single table (for data) and just needs to be parsed then rendered, where what I have is lots of relationships with data across many tables. I came up with another idea too, create a table to act as a queue for SQL inserts/updates. Save the raw SQL that way and extract the data from the statements when a moderator has a chance to approve or revoke the update. Only adding the data that was approved and with the new data a revision counter. This will mean lots of revision fields in my tables though, something I can deal with. SQL statements in SQL data might not work so well...

I'm still at the planning stages of a website, I'll be using PHP5, Postgres 8.2 and a framework, maybe the Zend Framework or CodeIgniter. I'm having a hard time trying to come up with a process for versioned content. What I mean by versioned content, I'll give you an example of how I want to use it. I want to be able to moderate content, on a page for a single book listing, a user can update the content of that page, perhaps a misspelling or additional information, but it must be approved. There may possibly be several new versions of the content waiting for approval as well. Being able to rollback data to a previous state may be useful to, but I haven't really seen the need for that quite yet. What I've come up with is just having an entry in my db book table with perhaps with a version field and another table to track which version of book data I should be using. This just doesn't seem right though, I'll be duplicating a lot of data this way. Also my data is managed over more then a few tables, if it were just one table's worth of data maybe my idea would work, but when its three to six I can only see it as impractical. So could someone offer me some practical advice? What is the more practised approach?