I would very much like to see that WCF 2.0 supports googles BreadCrumb microdata. See http://www.google.com/support/webmasters/bin/answer.py?&answer=185417 for detailed information.

In short, this will allow the breacrumbs to be shown on googles search result page. You can see it in action when you get search result from a xenforo, it will look like this: http://xenforo.com/community/attachments/google-microdata-png.11169/

Since google is, atleast in germany, the far most used search engine, i would really like to see such functionality in WCF 2.0, and the new WBB version, too.

The UserMassProcessingForm in the ACP is broken:
Fatal error: Call to undefined method wcf\acp\form\UsersMassProcessingForm::readCache() in [...]\feda5d4\wcf\lib\acp\form\UsersMassProcessingForm.class.php on line 392

I'd suggest using SPL-interfaces (Countable, Iterator) at certain classes like wcf\data\DatabaseObjectList

The inner error is displayed behind the input field rather than under it if the input field is small or the error text is short.

When reworking the language variables you should also take a look at error language variables since there are two types:

• wcf.acp.updateServer.serverURL.error.notValid (error after the error field - in this case serverURL)
• wcf.user.error.confirmEmail.notEqual (error in front of the error field - in this case confirmEmail)

Is there any reason not to delete the tempest update servers but to keep them?

I think the color of the copyright text in the installation should be lighter.
http://img153.imageshack.us/img153/889/copyrightwcf.png

Please remove that second input field during the installation that simply shows the installation url and replace it with "simple" text (in some way, of course, highlighted). I don't think having an input field that suggests that something can be entered - which is never the case here - isn't very user friendly.

Currently the global namespace is notated like this:

\Class
The wcf classes are imported (and used like this):
wcf\Class

I'd suggest for consistency to use this variant:
\wcf\Class

The classes are imported by use anyway, but if they were not the Back-Slash at the beginning would be even required to catch the right class!

Of course this has to be changed in the documentation as well, but I think this is easily managable by search'n'replace.

I'd prefer if the click target of WCF.MultipleLanguageInput would be the p element rather than the span element since you get a visual feedback (color change) if you hover over the p element but you have to be over the span element to be able to click, clicking on the p element alone has no effect.

I figured out two different coding styles concerning switch statements and shorthand if statements.

Type 1

switch statement

switch ($var) {
   case 1:
      print '1';
   break;
}

shorthand if statement

$newVar = ($var) ? true : false;

Type 2 (original wcf style)

switch statement

switch ($var) {
   case 1:
      print '1';
      break;
}

shorthand if statement

$newVar = ($var ? true : false);

I hope you decide for one of these types. But I think the original wcf style makes more sense, because:

• switch statement: the statement is more structured (the break keyword is optional and shouldn't be at the same level as 'case')
• shorthand if statement: the complete statement is enclosed and can be integrated into other statements easily:

$newVar = 'blub '.($var ? true : false).' blub 2';

https://github.com/WoltLab/WCF/blob/master/com.woltlab.wcf/objectType.xml#L7 doesn't work. This value isn't stored anywhere, see this screenshot, which causes an error (PHP Fatal error: Class name must be a valid object or a string in lib/system/clipboard/ClipboardHandler.class.php on line 191) if you try to select users.

This could be done when compressing the CSS.

The style is not visible in the last step of WCFSetup as it is read via the install.php which is already deleted at that time.

At the moment most abstract database object classes (DatabaseObject, DatabaseObjectDecorator, DatabaseObjectEditor, DatabaseObjectList) don't have the 'Abstract' prefix, but AbstractDatabaseObjectAction has. I assume that this is still a relict from when the names of interfaces didn't had an prepended I since there is the (I)DatabaseObjectAction interface.

Also, is there a specific reason why ProcessibleDatabaseObject isn't abstract?

May-be there should be a global convention if abstract classes have the Abstract prefix or not.

If you have more complex queries when selecting the data of a database object - for example a simple join with the users table to get the username - you have to copy and past the original wcf\data\DatabaseObject::__construct() method and just change the query.

Since such simple joins and additional selects aren't that rare, wouldn't it be nicer to have a protected wcf\data\DatabaseObject::getSelectQuery() method that simply delivers the needed query? If you have extra joins you can easily overwrite that method without having to copy the rest of the constructor which remains unchanged.

I think it's best if the system namespaces(/folder structure) reflect(s) the data namespaces which isn't the case currently with the package installation files. I would suggest creating an installation folder within the lib/system/package folder and moving all installation related files there so that you (e.g.) can find the package installation plugins in lib/system/package/installation/plugin/ (compare to the path of its database objects: lib/data/package/installation/plugin/).

The URL is hard-coded in the css. Maybe rewrite CSS on the fly or overwrite that one in the template?

If an event listener listens to several events, it will or can look like this: https://github.com/WoltLab/com.woltlab.wcf.comment/blob/master/files/lib/system/event/listener/UserProfileCommentListener.class.php. Whouldn't an abstract implementation be nice where the execute method tests if a method with the name of the event exists, and calls it then (may-be with the event object as an argument). The only (solvable) problem would be that the event wouldn't be allowed to be named 'execute', which is the case for the wcf\action\AbstractAction::execute() method.

Commit 2b4d274: LANGUAGE_ID isn't defined and causes an error.

There is an occurance of mysqli, but not PDO.

Add an option to disable the exception-details and instead log them somewhere, or disable them entirely.

At the moment, the name property of an object that is registered with a package installation plugin is an attribute sometimes and sometimes it's a child element.

Examples:

        <acpmenuitem name="wcf.acp.menu.link.system">
            <showorder>1</showorder>
        </acpmenuitem>

        <definition>
            <name>com.woltlab.wcf.clipboardItem</name>
        </definition>

In both cases the name is a unique value within the package.

A unification would be nice - I personally prefer the attribute.

cf. https://github.com/WoltLab/WCF/blob/master/wcfsetup/install/files/js/WCF.js#L2752

I think it would be nice if the options value of the HtmlOptionsFunctionTemplatePlugin would also support DatabaseObjectLists directly, or in general traversable objects.

Currently there are different ways how to name classes:
#1. 'VerbNoun':

• InstallPackageAction
• UninstallPackageAction
• ValidateActionException
  #2. 'NounVerb':
• OptionExportAction
• ...

I think all class names should be changed to 'NounVerb':

• PackageInstallAction
• PackageUninstallAction
• ActionValidationException / ActionValidateException

wcf\system\option\MultiselectOptionType still uses the old method signatures from WCF 1.1. Additionally its template also still works with an $optionData array rather than the object.

First error is that wcf1_package_installation_node just allows package and pip as values but requiredPackage (wcf\system\package\PackageInstallationNodeBuilder line 377) and optionalPackage (wcf\system\package\PackageInstallationNodeBuilder line 474) are also used.

If you've fixed that, you also need to change wcf\system\package\PackageInstallationDispatcher::install() since you get:

PHP Fatal error:  Call to a member function splitNode() on a non-object in ***/lib/system/package/PackageInstallationDispatcher.class.php on line 109

A SystemException is thrown if you try to overwrite old database tables during installation:

Fatal error: Could not execute prepared statement: SQLSTATE[23000]: Integrity constraint violation: 1217 Cannot delete or update a parent row: a foreign key constraint fails
Information:
error message: Could not execute prepared statement: SQLSTATE[23000]: Integrity constraint violation: 1217 Cannot delete or update a parent row: a foreign key constraint fails
error code: 23000
sql type: wcf\system\database\MySQLDatabase
sql error: Cannot delete or update a parent row: a foreign key constraint fails
sql error number: 23000
sql version: 5.5.9
file: ***/tmp/22abcc9e/install/files/lib/system/database/statement/PreparedStatement.class.php (77)
php version: 5.3.6
wcf version: 2.0.0 Alpha 1 (Maelstrom)
date: Thu, 22 Sep 2011 14:56:48 +0000
request: /woltlab/wcf2/installations/2011.09.22/install.php?step=createDB
referer: http://localhost:8888/woltlab/wcf2/installations/2011.09.22/install.php
Stacktrace:
#0 ***/tmp/22abcc9e/install/files/lib/system/database/editor/MySQLDatabaseEditor.class.php(95): wcf\system\database\statement\PreparedStatement->execute()
#1 ***tmp/22abcc9e/install/files/lib/system/database/util/SQLParser.class.php(289): wcf\system\database\editor\MySQLDatabaseEditor->dropTable('wcf1_acp_sessio...')
#2 ***/tmp/22abcc9e/install/files/lib/system/database/util/SQLParser.class.php(191): wcf\system\database\util\SQLParser->executeDropTableStatement('wcf1_acp_sessio...')
#3 ***/tmp/22abcc9e/install/files/lib/system/database/util/SQLParser.class.php(50): wcf\system\database\util\SQLParser->executeStatement('DROP TABLE', 'DROP TABLE IF E...')
#4 ***/tmp/22abcc9e/install/files/lib/system/WCFSetup.class.php(674): wcf\system\database\util\SQLParser->execute()
#5 ***/tmp/22abcc9e/install/files/lib/system/WCFSetup.class.php(264): wcf\system\WCFSetup->createDB()
#6 ***/tmp/22abcc9e/install/files/lib/system/WCFSetup.class.php(73): wcf\system\WCFSetup->setup()
#7 ***/wcf2/installations/2011.09.22/install.php(793): wcf\system\WCFSetup->__construct()
#8 {main}

Some thoughts about textarea styling:

• Add margin-top: 0px; since at least in Safari they've got a default top margin of 2px which doesn't look good with dropdowns in front (though not sure, if you will "officially" support dropdowns in front of textareas but you should for multi-language textarea inputs).
• The transition value shouldn't be all since resizing textareas with a delay is very strange.
• Add resize: vertical;, since horizontal resizing destroys the design most of the times.
• in combination with resizing: May-be a min-height for all and a min-width for each width class would be nice.

Are you sure that https://github.com/WoltLab/WCF/blob/master/wcfsetup/install/files/lib/system/package/plugin/ObjectTypePackageInstallationPlugin.class.php#L80 works? Shouldn't the $data['elements']['additionaldata'] array be build first?

See this in combination with #242, where I would expect that listclassname is in the additionalData array.

I'd suggest embedding the XSD directly via the raw-URL from GitHub, if it is possible. This way the are always on the current development state und you don't have to mirror it all the time.

User options error (I know, Alexander really likes them ;)):

error message: PHP error in file ***/wcf2/installations/2011.11.21/wcf/lib/data/user/option/UserOption.class.php (52): Argument 1 passed to wcf\data\user\option\UserOption::setUser() must be an instance of wcf\data\user\User, null given, called in ***/wcf2/installations/2011.11.21/wcf/lib/system/option/user/UserOptionHandler.class.php on line 110 and defined
error code: 0
file: ***/wcf2/installations/2011.11.21/wcf/lib/system/WCF.class.php (262)
php version: 5.3.6
wcf version: 2.0.0 Alpha 1 (Maelstrom)
date: Thu, 01 Dec 2011 21:48:59 +0000
request: /woltlab/wcf2/installations/2011.11.21/shdb/acp/index.php/UserAdd/?s=c14bc026baf2e76f3fae27ea48b70bb90ec34aa9
referer: http://localhost:8888/woltlab/wcf2/installations/2011.11.21/shdb/acp/index.php/UserList/?s=c14bc026baf2e76f3fae27ea48b70bb90ec34aa9
Stacktrace:
#0 ***/wcf2/installations/2011.11.21/wcf/lib/data/user/option/UserOption.class.php(52): wcf\system\WCF::handleError(4096, 'Argument 1 pass...', '***...', 52, Array)
#1 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/user/UserOptionHandler.class.php(110): wcf\data\user\option\UserOption->setUser(NULL)
#2 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(463): wcf\system\option\user\UserOptionHandler->checkVisibility(Object(wcf\data\user\option\UserOption))
#3 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(378): wcf\system\option\OptionHandler->checkOption(Object(wcf\data\user\option\UserOption))
#4 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(386): wcf\system\option\OptionHandler->loadActiveOptions('profile.aboutMe')
#5 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(386): wcf\system\option\OptionHandler->loadActiveOptions('profile')
#6 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(362): wcf\system\option\OptionHandler->loadActiveOptions('')
#7 ***/wcf2/installations/2011.11.21/wcf/lib/system/option/OptionHandler.class.php(118): wcf\system\option\OptionHandler->readCache(true)
#8 ***/wcf2/installations/2011.11.21/wcf/lib/acp/form/AbstractOptionListForm.class.php(82): wcf\system\option\OptionHandler->__construct('user-option', 'wcf\system\cach...', false, '', '', true)
#9 ***/wcf2/installations/2011.11.21/wcf/lib/page/AbstractPage.class.php(54): wcf\acp\form\AbstractOptionListForm->readParameters()
#10 ***/wcf2/installations/2011.11.21/wcf/lib/system/request/Request.class.php(58): wcf\page\AbstractPage->__construct()
#11 ***/wcf2/installations/2011.11.21/wcf/lib/system/request/RequestHandler.class.php(38): wcf\system\request\Request->execute()
#12 ***/wcf2/installations/2011.11.21/shdb/acp/index.php(3): wcf\system\request\RequestHandler->handle('shdb', true)
#13 {main}

I am forced to fill in the email signature in the options.

Is there any reason, that PermissionDeniedException has its own template without that stacktrace? Would be nice for debugging purposes.

This proposal ist nothing for immediate implementation, but more for long term planning. I just wondered if you might have considered using the github pages ( http://pages.github.com/ ) for WCf documentation. Currenty there were some articles in the wiki, but using gh-pages might prove better. For example, the installation instruction manuel (readme) will probably be updated for wcf 2.0 / WBB dragon. it could very well be put in the gh-pages branch. Furthermore, developer tutorials etc. could be shipped with gh-pages more conveniently than in the wiki.

Shouldn't the box shadow of error input fields be red instead of yellow?

If an p.error element occurs during installation (for example if the chosen database already contains a WCF installation with the given installation number) the background image can't be loaded since the images aren't extracted yet.

The installation-URL preview does not work in Google Chrome 13.0.782.112. The field is just empty. In Firefox it works fine.

Is Memcached experimental or not? In the German language-files there is no such notice, but in en.xml there is.

The pagination doesn't work correctly because the session id is missing.

An error occurs:

error message: PHP notice in file ***/lib/system/package/plugin/EventListenerPackageInstallationPlugin.class.php (46): Undefined index: elements
Stacktrace:
#0 ***/lib/system/package/plugin/EventListenerPackageInstallationPlugin.class.php(46): wcf\system\WCF::handleError(8, 'Undefined index...', '/Users/matthias...', 46, Array)
#1 ***/lib/system/package/plugin/AbstractXMLPackageInstallationPlugin.class.php(79): wcf\system\package\plugin\EventListenerPackageInstallationPlugin->handleDelete(Array)
#2 ***/lib/system/package/plugin/AbstractXMLPackageInstallationPlugin.class.php(44): wcf\system\package\plugin\AbstractXMLPackageInstallationPlugin->deleteItems(Object(DOMXPath))
#3 ***/lib/system/package/plugin/AbstractPackageInstallationPlugin.class.php(65): wcf\system\package\plugin\AbstractXMLPackageInstallationPlugin->install()
#4 ***/lib/system/package/PackageInstallationDispatcher.class.php(325): wcf\system\package\plugin\AbstractPackageInstallationPlugin->update()
#5 ***/lib/system/package/PackageInstallationDispatcher.class.php(105): wcf\system\package\PackageInstallationDispatcher->executePIP(Array)
#6 ***/lib/acp/action/InstallPackageAction.class.php(71): wcf\system\package\PackageInstallationDispatcher->install('1585cc9d')
#7 ***/lib/action/AbstractDialogAction.class.php(69): wcf\acp\action\InstallPackageAction->stepInstall()
#8 ***/lib/action/AbstractAction.class.php(38): wcf\action\AbstractDialogAction->execute()
#9 ***/lib/system/request/Request.class.php(58): wcf\action\AbstractAction->__construct()
#10 ***/lib/system/request/RequestHandler.class.php(51): wcf\system\request\Request->execute()
#11 ***/acp/index.php(10): wcf\system\request\RequestHandler->handle('wcf', true)
#12 {main}

The problem isn't just in this package installation plugins but in every one which relies on the child nodes of the element node since they are not added in wcf\system\package\plugin\AbstractXMLPackageInstallationPlugin::deleteItems().

Even when no user is marked the border of .clipboardEditor is visible.

Hello,

I'd like to suggest to add a more complex and capable error handling mechanism to the MultipleLanguageInput/I18nHandler to allow different error messages for the different inputs. While the input in one language might be correct, the input for another language might be wrong because of reason A and the input for a third language might be wrong for a reason B. So the javascript code should be able to change (respectively add or remove) the error message depending on which language is currently active (which shouldn't be to complicated).

Having the possibility to directly validate the input in the I18nHandler with more complex conditions would be nice but would require an abstraction for validators. To do it within the form class itself, I think having access to the $i18nValues via a getter would be nice.