* dhruvgoel92/ticket/11051:
[ticket/11051] fix spaces
[ticket/11051] add common_words variable
[ticket/11051] remove unnecessary comment
[ticket/11051] add get_word_len() in sphinx search
[ticket/11051] use get_word_length in search backend
[ticket/11051] use get_common_words in search backend
[ticket/11051] function instead of accessing property in search
[ticket/11051] add public functions for public properties
* bantu/ticket/8713:
[ticket/8713] Update untrimmed_variable() doc block.
[ticket/8713] Revert changes to ucp_profile, ucp_register and acp_users.
[ticket/8713] Trim password in auth_db to keep compatibility.
[ticket/8713] Call htmlspecialchars_decode() on transfer (e.g. ftp) passwords.
[ticket/8713] Rename untrimed_variable() to untrimmed_variable().
[ticket/8713] DRY: variable() and untrimed_variable() into a protected method.
[ticket/8713] Fix type_cast_helper.php doc blocks: Add punctuation etc.
[ticket/8713] Always trim array keys.
[ticket/8713] Add simple (non-nested) test case for untrimmed set_var().
[ticket/8713] Use \t in double quotes instead of tabs.
[ticket/8713] Use correct parameter for nested data.
[ticket/8713] Adjust test method name to other recursive_set_var() tests.
[ticket/8713] Do not trim login inputs
- $post_visibility is not boolean, so we need to check for == ITEM_APPROVED
- sync() already updates the topic/forum info, so we don't need to do that again
- use set_post_visibility() when changing the posts visibility
Should be ready for testing.
PHPBB3-9567
We should discuss this in an RFC again, but for now, we just fix the old state.
So moderators can only reply, when the topic is approved.
Also fixes a bug in the visibility check. We need to check the posts visibility
rather then the visibility of the topic. Because when the post is visible, the
topic is as well, but not the other way round.
PHPBB3-9567
This also makes sync('topic_visibility') obsolete, but we keep it for now.
Also fix a unit test, because ITEM_DELETED overpowers ITEM_UNAPPROVED
PHPBB3-9567
The function can not rely on the first post anymore, as that one could be soft
deleted but the topic still has approved replies which are still visible.
PHPBB3-9567
Before soft delete this was much easier, as an unapproved topic could only
have one post, because no one could reply to unapproved topics. Now we need
to run multiple queries to correctly reduce the post counts.
PHPBB3-9567
The Logic of $forum_ary was inverted, so if the array is empty, we can skip
the queries. We also should not merge passworded forums into the $forum_ary
as we removed them from that array right before that.
PHPBB3-9567
This is an additional query in some rare cases,
but it makes it much easier to use and understand.
This is mostly a preparation for the restore case.
PHPBB3-9567
By default, when a soft deleted topic is restored. Only posts that were
approved at the time of soft deleting, are being restored. Same applies to
soft deleting. Only approved posts will be marked as soft deleted.
If you want to update all posts, use the force option.
PHPBB3-9567
Limit the posts to a certain visibility and deletion time
This allows us to only restore posts, that were approved
when the topic got soft deleted. So previous soft deleted
and unapproved posts are still soft deleted/unapproved
PHPBB3-9567
The problems with having two different permissions are just too big and cause
huge queries, if they are granted differently. Also it's quite hard to decide
what should happen when a moderator has only one permission and the topic has
only posts of the two hidden types. To avoid all this, we merge them so it's a
simple switch: either the user is a moderator, then he can see all posts,
or he is not, then he can only see approved ones.
PHPBB3-9567
