pg_last_error does not work if no connection was ever established.
Therefore we must keep track of connection errors in postgres
dbal ourselves.
PHPBB3-10057
Calling nonexistent functions with @ destroys the script with
no feedback as to the cause of the error. Check whether
interbase functions exist before calling them.
PHPBB3-10057
This will make it autoloadable in 3.1. This commit breaks 3.0
since no code includes the error collector. Such include code
will be in its own commit since it will need to be reverted in 3.1.
PHPBB3-10057
PHP manual does not say that negative array indices are allowed,
so it's best to assume they are not guaranteed to work the way
one would expect.
PHPBB3-10057
Addresses two issues:
1. When pgsql extension is missing, @pg_connect would silently
abort execution. Check for pg_connect existence before calling it,
same with pg_pconnect.
2. When connection fails, the error reported by php is discarded.
User is shown the failure message without the reason for failure,
making debugging difficult. Collect the error (if any) via a
temporarily installed error handler, and display it if connection
failed.
PHPBB3-10057
Since isNormalized is less expensive than normalize[1] and normalization
will be applied repeatedly in most cases[2], it's more efficient to
check for isNormalized.
[1] http://area51.phpbb.com/phpBB/viewtopic.php?f=81&t=32718&p=208005#p208005
[2] phpBB 3.0 has a call to utf8_normalize_nfc wrapped around any
multibyte request_var call.
PHPBB3-9669
Implement the suggestion made by Adam in the ticket, this will add
an additional checkbox to the mass e-mail page. By checking this
the mass e-mail shall also be send to banned users. By default
banned users however are excluded from the mass e-mail.
PHPBB3-9581
* ticket/9549:
[ticket/9549] Display users in their primary group instead of their first group
[ticket/9549] Change default value of "sort legend by group name" to false.
[ticket/9549] Fix displaying empty groups
[ticket/9549] Fix language strings.
[ticket/9549] Only add group to legend/teampage when the checkbox is checked.
[ticket/9549] New method move() to move a group more than 1 up/down.
[ticket/9549] Fix some minor issues with descriptions and coding-guidelines.
[ticket/9549] Throw an error when the given field-name is invalid.
[ticket/9549] Make the class non static and extend delete_group function.
[ticket/9549] Add template changes for subsilver2.
[ticket/9549] Enhance teampage and legend functionality
[ticket/9549] Add the module and files for the ACP.
[ticket/9549] Update database with the new config values and columns
[ticket/9549] Enhance teampage functionality with a new class, group_positions.
Conflicts:
phpBB/install/database_update.php
* ticket/hanakin/10001:
[ticket/10001] Created the new styles within colours.css to handle the displaying of the forum & topic images
[ticket/10001] Created new Template variable to house class names based on $folder_img value, Modified prosilver template files to utilize class for forum & topic images through out template via the newly created Template variable, Created the new styles within colours.css to handle the displaying of the forum & topic images
* develop-olympus:
[ticket/9874] view_log() performs unneeded count query over all log entries.
[ticket/7834] Topic time didn't update when first post was deleted
[ticket/9997] Fixed an inconsistency in the Moderator Control Panel
[ticket/9872] Removed some useless code that broke delete_posts
When the first post of a topic was deleted, the topic time didn't
update - it should have changed to the time of the next post.
This commit simply applies lefty74's patch posted in the ticket. It gets
the post time of the next post from the database, and updates the thread
accordingly.
This patch is not my work at all and all credits go to lefty74, I just
transferred it onto GitHub
PHPBB3-7834
When in the ACP, there is the option to delete a user and all their
posts. This would then call the user_delete function and define $mode as
'remove'.
On lines 485-521 was some code that would delete their topics, then
after that there would be a call to delete_posts - which would also
delete their topics. It would not update the board statistics, and the
thread count would remain the same, even though several had been
deleted. It stopped delete_topics functioning correctly, so
delete_topics would not update the board statistics either.
My solution to this is to delete lines 485-521 and allow delete_posts
to call delete_topics, thus updating the thread count in the statistics.
PHPBB3-9872
* develop-olympus:
[ticket/10056] Corrected a typo in Firebird name.
[ticket/10041] Use send_status_line more in download/file.php
Conflicts:
phpBB/download/file.php
* develop-olympus:
[ticket/7778] Update all the schema files
[ticket/7778] Add the column change to `mysql_upgrader.php`
[ticket/7778] BBCode single limit
Conflicts:
phpBB/install/database_update.php
