490056 - Make noMac and noUnix SHOWFOR filter appear in new search results

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

On a Mac, at least, https://support-stage.mozilla.org/tiki-newsearch.php?locale=en&q=options+window&where=d&sa=&filter_lang=1&l=en&en_too=1&lastmodif=0&type=0&author= yields summaries that are missing the phrase "On the menu bar", evidenced by the ", ," section in the article summaries.

This is probably platform-specific SHOWFOR fallout -- I haven't yet tested Windows

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

FWIW, I'm guessing this is a regression from bug 405028?

Comment 2

[Laura Thomson :laura]

I concur, and think it's probably a regression from 
https://bugzilla.mozilla.org/show_bug.cgi?id=488429#c10

Comment 3

[E. Cooper [:ecooper]]

Attachment: v1

Any showfor block that wasn't strictly a 'win' was taken out. Apparently, 'noMac' is for when windows and linux are identical, and I'm sort of dumb.

Comment 4

[Laura Thomson :laura]

Comment on attachment 374522 [details] [diff] [review]
v1

I didn't know either.

Commit, but let's hold off on another reindex bug until stephend and krupa have had a chance to run through all the search bugs.  (Then file one/reopen the old one)

Comment 5

[Chris Ilias [:cilias]]

I'm having trouble understanding this bug. In the KB, "On the menu bar" should always be SHOWFORed as Mac-only. In bug 488429, wasn't the fix to show Firefox 3.0/Windows content only?

Comment 6

[David Tenser [:djst]]

Chris: the content block "optionspreferences" contains noMac rules, which are stripped from the summary. Eric's patch fixes that.

Comment 7

[Chris Ilias [:cilias]]

That's not going to put "On the menu bar" in article summaries.

Comment 8

[David Tenser [:djst]]

Guess you didn't read the bug report comments... (summary changed)

Comment 9

[Chris Ilias [:cilias]]

I did. That's what confused me!

Comment 10

[E. Cooper [:ecooper]]

Attachment: v2

The patch also includes a fix for bug 490069.

Comment 11

[E. Cooper [:ecooper]]

r24910/r24911

When this is ready to QA, please make a note so we can request reindexing.

Comment 12

[Paul Craciunoiu [:paulc]]

Laura: here's an example where IT could help us out by setting up some way for webdev to run reindexing more easily on staging. You can better say if this is something we should have or not, but I personally find it beneficial for both sides. The one dangerous issue I see is overloading the server - which could be solved by limiting running the reindex to one every so often.
Could we have a reindexing script that webdev would have access to run on staging only?

Comment 13

[matthew zeier [:mrz]]

Are you thinking of something that runs out of cron or some website with a button you push when you want it done?

Comment 14

[Laura Thomson :laura]

The original plan was to cron reindexing once it was no longer broken.  Paul, why don't you file a bug to set up reindexing under cron on stage?

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

An additional testcase from duped bug 490069: load https://support-stage.mozilla.org/tiki-newsearch.php?locale=en&q=options+window&where=d&sa=&filter_lang=1&l=en&en_too=1&lastmodif=0&type=0&author and make sure there are no "ToolsFirefoxEditMenu" results.

Comment 17

[Laura Thomson :laura]

This should now be reindexed on staging as per bug 490481, however I still see the problem on stage.

Comment 18

[E. Cooper [:ecooper]]

Since this is a bug involving descriptions, webroot/lastindexingtime-f.txt and webroot/lastindexingtime-f.txt need to be deleted prior to indexing and index rotation (as mentioned in bug 490481).

If that didn't happen, the new description text won't show up (since the one in the tables will be used instead of a new one). The same is true if indexer --all --rotate didn't happen (since the new indexes won't be used).

Comment 19

[Laura Thomson :laura]

ccing chizu for comment.

Comment 20

[E. Cooper [:ecooper]]

(In reply to comment #18)
> Since this is a bug involving descriptions, webroot/lastindexingtime-f.txt and
> webroot/lastindexingtime-f.txt need to be deleted prior to indexing and index
> rotation (as mentioned in bug 490481).
> 
> If that didn't happen, the new description text won't show up (since the one in
> the tables will be used instead of a new one). The same is true if indexer
> --all --rotate didn't happen (since the new indexes won't be used).

/scripts on staging not being up to date is also a possibility.

Comment 21

[chizu]

/scripts is up to date, cron updates it every 10 minutes. 25316 is the current revision.

I think the problem may have been that rotating the indexes tried to run while searchd was stopped. I fixed this and tested an index rotate. Is it working now?

Comment 22

[Laura Thomson :laura]

Still broken.  Chizu, did you delete the files prior to indexing as ecooper suggested?

Comment 23

[chizu]

Here's the script in cron, runs in the webroot directory:
sudo -u apache searchd --stop
/bin/rm lastindexingtime-f.txt
/bin/rm lastindexingtime.txt
/usr/bin/php manual_index.php
/usr/bin/php manual_index_forums.php
sudo -u apache searchd
sudo -u apache /usr/bin/indexer --all --rotate

Comment 24

[Laura Thomson :laura]

OK, back in Eric's court.  Thanks chizu.

Comment 25

[E. Cooper [:ecooper]]

This looks fixed to me. 

https://support-stage.mozilla.org/tiki-newsearch.php?locale=en&q=options+window&where=d&sa=&filter_lang=1&l=en&en_too=1&lastmodif=0&type=0&author

Stephen or Chris can you take a look?

Comment 26

[Laura Thomson :laura]

And now...it's fixed for me too.  Closing.

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me using comment 25, comment 16, comment 0.