[FIXED] Forums - Inbox Folders Misaligned

[HMC (FMF) (Ret) T. Savage]

Reproduction Steps:

1. Create 4 folders (ie, "Folder One", "Folder Two", "Folder Three","Folder Four")
2. Delete "Folder Two" by from the contents view > settings > delete
3. Move an Inbox message to "Folder One"
4. That folder will be opened with the message contained
5. Move an Inbox message to "Folder Four"

 

Expected Outcome:

• "Folder Four" is opened with the message contained

 

Actual Outcome:

• "Folder Three" is opened with the message contained

 

What appears to be happening is the "Move Message" drop-down box is blindly listing the folders as numbers 1 through 4: "Inbox", "Folder One", "Folder Three", and "Folder Four" -- The problem is that "Folder Two" is number 3, "Folder Three" is number 4, and "Folder Four" is number 5 so the drop-down is misleading on which folder is being select (ie, I choose "Folder Four" but the drop-down assigns it to number 4 which is actually "Folder Three"). I tried to hack into working by editing the HTML to have the correct folder names, but the forums has input validation that rejects my edits and forces it to be between numbers 1 through 4.

 

Edited May 31, 2020 by HM3 (FMF) T. Savage
Grammar clarity

[Sgt (Ret) Atom]

Greetings,

I've tried to replicate using the steps that you have given. Unfortunately, I only achieved the expected outcome. Are you able to provide anything further to support this bug so it can be looked into further?

Respectfully,
Cpl Atom
S-1 GPL

[HMC (FMF) (Ret) T. Savage]

@Cpl Atom, one thing that may help with consistency of results would be 2-fold:

 

1. Use a fresh account (recommended so your folders don't get misaligned)
2. Refresh your browser between each action that you take (ie, creating folders, deleting folders, moving messages)

 

Here is a screen recording of me reproducing this bug on a fresh account with a single message.

 

https://streamable.com/iwak9j

 

 

Thank you for your help.

 

Respectfully submitted,

 

HM3 (FMF) T. Savage

Edited May 31, 2020 by HM3 (FMF) T. Savage

[HMC (FMF) (Ret) T. Savage]

After two years of no longer using folders because my account's folders were broken by the above issue, it has been tracked down and resolved! Well... Until we update to a newer version of IPS and I have to fix it manually. So here's to hoping Invision Community resolves this issue with the following synopsis. Enclosed, I will use the example folder names above to keep things consistent and easier to illustrate.

 

What was the issue?

 

When using folders, you're able to reduce the size of your inbox and organize messages to be easier to find. I created multiple folders and loved the new organization and mild "neatness" I began to experience. As I moved positions, some of those folders became irrelevant and I deleted those folders to restructure.

 

 

When I started reorganizing messages in my inbox, I quickly discovered the issue above. I was moving messages into "Folder Four" using the message list checkbox and dialog that prompted me which folder to move the message(s) to, but my messages were landing into "Folder Three" instead. I thought it was a one-time issue, so I again moved the message trying "Folder One" and it worked flawlessly. I retried "Folder Four", but the message was put into "Folder Three" once again.

 

So let's look at the code for the "View Folder" drop-down and see what sort of "identifiers" are used by IPS when I try to navigate these folders.

 

<!-- Irrelevant HTML attributes removed for readability -->
<ul id="elMessageFolders_menu">
  <li data-ipsmenuvalue="myconvo"><a href="https://forums.example.com/messenger/"><span data-role="folderName">Inbox</span></a></li>
  <li data-ipsmenuvalue="0"><a href="https://forums.example.com/messenger/?folder=0"><span data-role="folderName">Folder One</span></a></li>
  <li data-ipsmenuvalue="2"><a href="https://forums.example.com/messenger/?folder=2"><span data-role="folderName">Folder Three</span></a></li>
  <li data-ipsmenuvalue="3"><a href="https://forums.example.com/messenger/?folder=3"><span data-role="folderName">Folder Four</span></a></li>

  <li><a href="..." data-action="addFolder" id="elAddFolder">Add Folder</a></li>
</ul>

 

Very quickly, we can see the URLs contain a number sequence EXCEPT the position 1 is missing. If your recall my steps above, the folder in between "Folder One" and "Folder Three" would have been the since-deleted "Folder Two". So I validated this by creating one more folder called "Folder Five" and then I deleted "Folder Four".

 

<!-- Irrelevant HTML attributes removed for readability -->
<ul id="elMessageFolders_menu">
  <li data-ipsmenuvalue="myconvo"><a href="https://forums.example.com/messenger/"><span data-role="folderName">Inbox</span></a></li>
  <li data-ipsmenuvalue="0"><a href="https://forums.example.com/messenger/?folder=0"><span data-role="folderName">Folder One</span></a></li>
  <li data-ipsmenuvalue="2"><a href="https://forums.example.com/messenger/?folder=2"><span data-role="folderName">Folder Three</span></a></li>
  <li data-ipsmenuvalue="4"><a href="https://forums.example.com/messenger/?folder=4"><span data-role="folderName">Folder Five</span></a></li>

  <li><a>Add Folder</a></li>
</ul>

 

The folder number for "Folder Five" didn't change! So I was moved forward under the assumption these integers correlated to account-specific folder IDs.

My folder issues only appeared while I was trying to move messages with the "Move conversations" dialog accessible when using the message list check boxes. Let's see what the dialog drop-down thinks those folder numbers should be.

 

<select name="move_message_to">
  <option value="myconvo" selected>Inbox</option>
  <option value="0">Folder One</option>
  <option value="1">Folder Three</option>
  <option value="2">Folder Five</option>
</select>

 

There's our issue! The dialog is re-indexing our folder numbers instead of using the correct number found everywhere else. Moving messages to "Inbox" or "Folder One" always worked because the folder ID was correct for those two. So that's our problem but.. What's causing this? How can it be fixed?

 

Why are the option values wrong?

 

Since joining the Web Team (which has since been absorbed by our Data Systems S-Shop), I'm no stranger to poking around in the IPS code to track down minor issues that mostly stemmed from the server setup or IPS extensions. I began with inspecting the template's files to see if it was the one building the form incorrectly. With next to no leads, I remembered that this issue has existed through multiple IPS updates and changing themes between those updates, so this form must be getting generated by the IPS code. I decided to take a look at the dialog code once more to see WHERE does that form submission goes.

 

<form action="https://forums.example.com/messenger/?page=1&amp;do=moveForm&amp;ids=12345" method="post" enctype="multipart/form-data">
  <!-- ... -->
</form>

 

Thankfully, IPS's routing conventions make it easy to track down where that form submission is going. It's hitting a controller that's not explicitly listed here so it's likely in the "core" module and it's going to a function called "moveForm".

 

A quick search of the "applications" and "system"  directory for "function moveForm" yielded a controller named "_messenger" found within the core's "front/messaging" module. This "moveForm" function wasn't particularly complex and I quickly found a "select" field with the name of "move_message_to" that we saw in our dialog HTML - I think we have a match!

 

<?php
...
class _messenger extends \IPS\Content\Controller
{
  ...
  protected function moveForm() {
    ...
    $folders = json_decode( \IPS\Member::loggedIn()->pconversation_filters, TRUE ) ?? array();
    ...
    $form = new \IPS\Helpers\Form;
    $form->add( new \IPS\Helpers\Form\Select( 'move_message_to', NULL, FALSE, array( 'options' => array_merge( array( 'myconvo' => \IPS\Member::loggedIn()->language()->addToStack('inbox') ), $folders ), 'parse' => 'normal' ) ) );
    ...
  }
}

 

I was able to quickly see that there is a list of folders attached to my account. I brought out the oldest debugging trick in the PHP developer book and I injected a "var_dump($folders);" momentarily so I could see the structure of that data.

 

<?php

$folders = ...;
...
var_dump($folders);
// Outputs: array(3) { [0]=> string(10) "Folder One" [2]=> string(12) "Folder Three" [4]=> string(11) "Folder Five" }

 

So from this, we can see that the folder numbers are in tact. So it must be related to the form generator. After years of developing in PHP (and a good portion of my time debugging because it's honestly a crappy developer experience), a particular piece of code dealing with the array of folders caught my eye.

 

<?php
...
array_merge( array( 'myconvo' => \IPS\Member::loggedIn()->language()->addToStack('inbox') ), $folders )
...

 

That was it! But to make sure we are on the same page as to WHY the "array_merge" is the problem, let's take a look at the PHP docs for that function.

 

Quote

Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one. If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

Values in the input arrays with numeric keys will be renumbered with incrementing keys starting from zero in the result array.

 

The last sentence is exactly what is happening to our folders. In PHP, all keys are implicitly converted to integers unless it is a string not representing a decimal integer; in addition, PHP maintains an internal iterator to track the ordering of array items. In our case, our array of folders has numeric keys and they are being renumbered starting from zero as they are appended to the initial array that contains the default "Inbox" option.

 

<?php
// Example from the PHP Manual - https://www.php.net/manual/en/language.types.array.php
$array = array(
    1    => "a",
    "1"  => "b",
    1.5  => "c",
    true => "d",
);
var_dump($array);
// Outputs: array(1) { [1]=> string(1) "d" }

 

How to we fix it?

 

Merging two arrays in PHP when you want to maintain the key values is very trivial.

 

<?php
...
// First, we start with our first array that has the "Inbox" option
$moveOptions = array ( 'myconvo' => \IPS\Member::loggedIn()->language()->addToStack('inbox') );

// Next, we loop over our list of folders, adding them to the array and maintaining their key value
foreach ($folders as $id => $name) {
   $moveOptions[$id] = $name;
}

// Finally, we supply our new $moveOptions array in place of the array_merge
$form->add( new \IPS\Helpers\Form\Select( 'move_message_to', NULL, FALSE, array( 'options' => $moveOptions, 'parse' => 'normal' ) ) );
...

 

A quick inspect of the dialog HTML and a test move of a message shows that issue has been fixed!

 

<select name="move_message_to">
  <option value="myconvo" selected>Inbox</option>
  <option value="0">Folder One</option>
  <option value="2">Folder Three</option>
  <option value="4">Folder Five</option>
  <option value="69">Winning Moments</option>
</select>

 

Conclusion

 

Don't use PHP unless you have to because of some sort of hosting or compatibility reason - reconsider.