>Duplicate entry 'PMAttachments' for key 'class'

Same...

No Joy on install, great product if it worked something that has been lacking in VB for a long time. Wish it was working .

So, it doesn't work ?

yep, does not work, actual error:

the problem is, that:

vB_Types::instance()->getContentTypeId('PMAttachments_PrivateMessage' )

returns an empty value.

for everyone with that duplicate errors, thats because database fields get added to existing tables before the script breaks.

need to remove a few:
from table "pm" remove "attach" and "attachmap"
from usergroup remove "advpmpermissions"
from packages remove the entry "PMAttachments"
from contenttype remove the entry "PrivateMessage"

the productinstaller of vbulletin is unable the remove database entries when theyre duplicate, even if you choose overwrite as an option, plus the script actually breaks before putting the entry into the products manager...

ps: bitte koenntest du die titel fuer die plugins ins englische umbenennen, fuer unsere uebersee freunde;-)

ps: even after fixing the obvious errors (VBForum_PrivateMessage instead of PMAttachment_PrivateMessage...), opening the newattachment.php link causes an error

looking at the link i see a major difference between a working and non working url for calling newattachment.php:

doesnt work:
does work:
just a first glimpse...

Thanks Andreas!

I have completed a similar hack for my company (in the core files, not a plugin). Your code examples helped me tremendously. Very, very grateful! :) Let me know if I can reciprocate.

Aside from the headaches of cleaning up our database tables from a previous failed Product XML Upload failure due to "Database Error" so as to return all the table entries and fields to a virgin state, I also ran into the following faults in the original XML file:

1. Very Minor - Descriptions alternate between German and English in both the XML file and portions of the instructions files -- all the Plugin titles are in German for instance. I don't want to harp (or even really complain for that matter) on this one because language is inherently relative to the observer, but I figured I should probably mention it for consistency's sake.
2. On Lines 160 and 261 of the XML file, the SQL Query does not properly reference tables that have a vBulletin TABLE_PREFIX attached to them... The initial FROM statement is correct, but the "as attachment" portion of the Query is missing, so the query fails a bit further in when the table.fieldid "attachment.contenttypeid" is called. This will only fail for sites that have defined a TABLE_PREFIX value, but should be corrected.
3. The more troublesome one (for me) was on Line 160 (again) where "attachment.contenttypeid" is set:
   
   
   PHP Code:

   ---

   attachment.contenttypeid = " . vB_Types::instance()->getContentTypeId('PMAttachments_PrivateMessage') . ") 


   ---

   It appears that the call to getContentTypeId is coming too early in the process, as the value returned is an empty string rather than the intended value. However, this same code works later on come line 261, so clearly it is an order-of-execution issue. This suggests that this query should be moved until after the "pmattachments" row has been added to the "packages" table so that the call does not fail.
   
   I temporarily worked around this issue by hard coding the next Auto Increment value to be assigned to the next record ID for the "packages" table so that I could at least get the Product installed ("13" in my case, after some earlier failed attempts and cleanups).

I apologize for having to submit these changes rather than a corrected XML Product File. I am comfortable enough to make minor tweaks to the XML files, but I am not comfortable enough with my knowledge of the XML file's layout to make wholesale changes so that I can change the order of execution of the "contenttype" table's record insertion. Especially not comfortable enough to submit something that others will run on their servers!



Despite my concerns, I do greatly appreciate your sharing this plugin with us as our users genuinely want the functionality without having to wait for vBulletin to get around to releasing such. I hope my suggested amendments will help both yourself and other users trying to install the product. The instructions user nevbear666 provided for backing out the database changes were most valuable to eventually getting the product installed (after making my above changes), they certainly saved me some time.

works good :D

on which vb version ?

I too got an SQL error. Amazing some people put their unfinished and error-prone product to public use and then not willing to help. Bad product.