Any further updates on fixage? Links embedded in wiki not selectable/clickable.

David

Could you link me to an example wikipost that has links?

My update is that I'm currently in a fight with a major product manager at IB because they did a bunch of stuff with zero input from people who use the product. Like the latest version of wikiposts not supporting revision history.

Here's one that I posted earlier:

David

Links in the wiki work fine for me.

That said, unless a link is just a raw URL, there’s no way to tell it’s a link—no underlining, different font color, or other visual distinction is generated. This, too, is a change from the past, and most unwelcome.

Possibly because I just edited it to test out. When I originally looked at it, the links were indeed not working

Yes - links now working. Was thinking that any software fixes would not require any further maintenance of an existing wiki and its links since it would be better if the developers would simply fix the wiki code and not force more manual activity across all of FlyerTalk.

David

Completely concur with this.

David

While the links from the wiki above now work - they _do_not_ open in another tab or window.

David

I was able to edit the wiki for the LAX happy hour thread. Only issue that I see is that the timestamp for the update is still showing 1969?

Wikis continue to be super messed up. Lack of history, some still not showing up on mobile.

I just had a bizarre experience editing the wiki in this thread as well. I edited some text that was right around the cut-off when the wiki was collapsed (i.e. before you hit Show More). The text stayed fine when editing the wiki, but no matter what I did, when I saved the wiki, it kept getting truncated with an ellipsis in the same place. I eventually solved it by deleting that whole block of text, saving it, then adding it back. But super weird.

We essentially need an entirely new release developed for wikiposts. They removed a bunch of features (revision history being arguably the biggest one) for some... unknown reason. I'll take a look at that thread you linked though, that seems like an outright bug. Was there any special formatting you did with the text?

You can see what I think is the same bug in the wiki at https://www.flyertalk.com/forum/inte...astercard.html. The collapsed wiki cuts off the text in the middle of a word—which is another problem in itself—and inserts a carriage return mid-word (anniversar CRLF y) when the wiki is expanded.

Very strange. Other than the challenges with infinite scroll on mobile, wikis were something I thought worked pretty well, for the most part.

It was bold and red, but I get the feeling that wasn't the cause...

The text was bold and red, butThat's exactly the issue I was having. In my case, the cut was after a comma, but I think it was just a coincidence based on the number of characters that were displayed when the wiki was collapsed.

IMO wikis—which are apparently “Expert How-Tos and Guides” now—worked much better in the past. Much of the problem is the way that text formatting was materially degraded across the board a few years back. (An example: try indenting the bullet list in the sandbox wiki above. If it can be done at all, it’s far too hard/obscure.) But some parts are specific to wikis.

I’m not talking about the stupid way the editor appends another CRLF every time a wiki is edited, which is the least of the annoyances. It’s the fact that several things work very, very badly, starting with the supposedly WYSIWYG editor, which doesn’t accurately display the resulting formatting. And there’s a recurring issue where it is literally impossible to insert a CRLF between paragraphs. Need I even mention the fact that a FT thread URL inserted into a post, as I did above, autogenerates a link with the thread’s title, but this desirable behavior is lacking in the wiki editor?

It’s like working in a restaurant kitchen where periodically some genius decides that the knives need to be duller, the gas flow to the stove burners needs to fluctuate erratically, and the saucepans would work better with scorches on the inside. You can still prep & cook food, but it’s needlessly difficult.

Cancel will perform a Save Changes
 

If you edit a wiki and make a mess of it, then try to cancel... sorry for you, but your cancel is now 'saving the changes' anyway.

The issue happened on two different laptops, Chrome, Firefox, Edge, it makes no difference. Guess this started when most of the other issues were fixed recently.

Best work around is to close your browser (tab), I guess.

This is inexcusable. People have been fired for less, and justifiably. Putting aside the sheer stupidity of some of the intentional changes, how the [EXPLETIVE] do you push such garbage, buggy code into production instead of doing basic testing?