Subtle changes, bugs and feedback

Well, let me temporarily break it again whilst I test something.

Yeah... GZIP and Deflate handling is messing up static files served by /api/v1/files . The result is that the request is chunked and only the first chunk is served and then the connection hangs.

Oh well... no GZIP on the API then.

Interesting characters being added to URLs:-

The following URL is manually typed in:-

https://facebook.com/groups/regentsparkcycling/

And clicking on the link works, but if you copy and paste the text into the address bar there's a "soft hyphen" (0xAD or %C2%AD in URL encoding) between the p and a characters that wasn't there originally.

What is the error?

What are the interesting characters being added?

Looks good to me.

Here's what 'cat -vet' on a selection of the page source looks like:-

<p>The following URL is manually typed in:-</p>$
$
<p><a href="http://microcosm.app/out/bqgNg" title="facebook.com/groups/regentspar..." rel="nofollow" target="_blank">facebook.com/groups/regentsparkcM-BM--ycling/</a></p>$
$
<p>And clicking on the link works, but if you copy and paste the text into the address bar there's a "soft hyphen" (0xAD or %C2%AD in URL encoding) between the p and a characters that wasn't there originally.</p>$

Note the meta chars "M-BM--" in the middle of the text representation of the URL.

Ah right... yes, that is international.

And as you say... clicking on the link works.

The ­ unicode characters were added after a number of very long URLs were posted and broke the layout of certain long posts (notably the "lists of" links).

Because there is no internal space in a URL no amount of telling CSS to wrap text worked. The only solution was to add a form of zero-width whitespace that would allow browsers to wrap a long and solid URL at certain points. We add a ­ every 25 chars so that the browser width can be used to wrap at the appropriate point.

As you point out, clicking the link and following the href still works. In fact, the href is the only thing we will ever guarantee to work.

Ah right... yes, that is international.

So you do it for links regardless of the country of origin? Is that deliberate, or, as we might say in English, intentional?

Right-click on link, "copy link address" (or whatever it's called in your browser. They all have it.)

Fair enough...

Because there is no internal space in a URL no amount of telling CSS to wrap text worked.

The website monkeys at our place pointed me at: https://kenneth.io/blog/2012/03/04/word-wrapping-hypernation-using-css/ which they say works across all major supported browsers.

Your website monkeys are partially right.

It does work, on "supported" browsers, and it works inconsistently, and it doesn't work on older IE or the various older browsers shipped to phones, and it doesn't work on URLs in anchor tags when there are no good candidate places to break the text.

I know all of that because we did it. We tried the hyphenation CSS and found it to be too inconsistent across browsers, and too problematic on some special things (link anchors).

Not that any of that matters... one can click the link to end up at the destination. The text between anchor tags is not the link itself, it's just an indicator of where the link will go, and I have zero issue with using ­ to solve the problem of long URLs breaking page layout.

Actually it's not even long URLs, just long solid blocks of text will be broken if there are no candidate hyphenation points within it.

I should ask... what is wrong with just clicking the link?

I should ask... what is wrong with just clicking the link?

Well, for a start the use of redirects to conceal the eventual destination causes people not to trust just clicking

Updated iPad to ios 8.4 and got logged off. Tried to log back in but getting a message that persona doesn't support safari. Posting this from iphone

Persona doesn't work in private browsing mode on Safari as Safari prevents the setting of cookies for persona.org.

Switch out of private browsing mode and it should work.

Thanks!

That fixed it?

Having a / in a title seems to screw up searching for it. For instance
For Sale: British Made Backpacks/Daysacks
Can't be found searching on british backpacks. You need the whole backpacks/daysacks or it won't find anything

Whereas something like
For Sale: British Made Mini Messenger Bags
Can be found searching on british bag

Noticed this on a few thread titles.

It's not the / , but the lack of space between words.

The search uses a language search, which uses natural phrases and a process called stemming.

This search engine attempts to take a word like "cycling" and "cycle" and will save both as "cycl-" for the purpose of a search. Then when you search "cycling" it actually searches "cycl-" and finds matches that have minor differences in plural, modifier, etc.

The problem comes that when there is a lack of a space, i.e. "cycling/running", this produces a different output... "cycling/running"... why no stem? Because it cannot find the whole word (up to the next space) in a dictionary and therefore cannot determine the modifiers that are valid.

Anyhow... "cycling/running" is not a hit for the stem "cycl-" that you may search for.

The only way to ensure the search engine works is to use spaces around words, or to restrict the punctuation used to separate words to the classic ones: comma, full-stop, question mark, exclamation mark.

The search engine is doing what it should do, because the major complaint of the old one was that it was too precise ("cycle" would never match "cycles"). That is now solved as we're using a language search, but it comes at the loss of exact match precision for non-dictionary words (and lack of spaces in your example is creating a word "Backpacks/Daysacks").

Solution: Anyone selling stuff, to ensure it gets found, really shouldn't smash words together without spaces using /. Instead, use a comma delimited list with spaces.

Doesn't "/" count as a word break in most pattern-matching systems? Is there a downside to counting it as a word break?

All I can say is: "Not according to PostgreSQL".

Cheers for the detailed answer although a shame it doesn't seem to have an easy solution.

thats just how search works.

So we're accepting a degraded user experience because of an unexplained quirk in the chosen technology?

If that was the way we did it we'd still be butchering vBulletin.

Yeah, it's a shame that this part of the language configuration isn't surfaced through the PostgreSQL config files.

I've looked through the config: http://www.postgresql.org/docs/9.2/static/textsearch.html

And it doesn't look like there's any way to control what is regarded as word separators and punctuation.

What should following a microcosm/forum do? I went to Current Projects and "followed" it, (and then I also hit "mark all read" for good measure).

Since then a few threads have been updated, but they don't appear on my Following page.

Also, are you taking questions/comments on the API?

edit: ...and still offering API keys?