Moodle
  1. Moodle
  2. MDL-14325

Global search doesn't work in 1.8.5

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.8.5
    • Fix Version/s: None
    • Component/s: Global search
    • Labels:
      None
    • Environment:
      Linux, php 5.2.5
    • Affected Branches:
      MOODLE_18_STABLE
    • Rank:
      4276

      Description

      After upgrading Moodle from 1.8.4+ to latest 1.8.5+ global search stopped working. I have identified a number of issues but some are still there.

      • search/indexersplash incorrectly assumes that version of Moodle 1.8 is at max 2007021541 - this will result in fact that indexersplash will not run
        if ($CFG->version <= 2007021541){ // 1.8 branch stable timestamp
        but now it is 2007021550
      • search/documents/physical_doc and physical_pdf will not index documents due to line
        $text_converter_cmd = "{$moodleroot}{$command} \"$file\"";
        after changing it to (trere are already apostrophes around the file name)
        $text_converter_cmd = "{$moodleroot}{$command} $file";

      Even with these changes, indexersplash will not finish indexing successfully

        Issue Links

          Activity

          Hide
          Valery Fremaux added a comment -

          Thanks for confirmation of quote problem. I identified distinct behaviour on Unix and Windows (and I'm developing shamely on Windows XP !!)

          For the branch timestamp, this is actually a problem, as I relied on a comment in version files that seemed to tell that the reference date for a branch WOULD NOT change after a fork. But seemfully I'm wrong on that point.

          Maybe MartinD can give me a way : I first tried to get the code compatible for 1.8 versions, but upgrading to the build_navigation() new method till 1.9. This was initially done for saving efforts in syncing the code in my dev structure (7 Moodle instances to check, sync and test !!), maybe should I admit the code MUST fork also... but should there be a magic way to recognize all PRE-1.9 versions...

          maybe using a function_exists('build_navigation') would be worthy ?

          For quoting problem : I change it in all branches

          Show
          Valery Fremaux added a comment - Thanks for confirmation of quote problem. I identified distinct behaviour on Unix and Windows (and I'm developing shamely on Windows XP !!) For the branch timestamp, this is actually a problem, as I relied on a comment in version files that seemed to tell that the reference date for a branch WOULD NOT change after a fork. But seemfully I'm wrong on that point. Maybe MartinD can give me a way : I first tried to get the code compatible for 1.8 versions, but upgrading to the build_navigation() new method till 1.9. This was initially done for saving efforts in syncing the code in my dev structure (7 Moodle instances to check, sync and test !!), maybe should I admit the code MUST fork also... but should there be a magic way to recognize all PRE-1.9 versions... maybe using a function_exists('build_navigation') would be worthy ? For quoting problem : I change it in all branches
          Hide
          Miroslav Fikar added a comment -

          Some more:

          1. [[usemoodleroot]] - string not defined in Administration-Modules-Blocks-Global Search

          2. linux executables (pdftotext, antiword,...) are not executables - have missing X bit. It is annoying as it is not mentioned in installation instructions.

          3. Typo in physical_pdf and probably elsewhere (doc,...): mtrace('Error with pdf to text converter command : exectuable not found.');
          ->
          executable

          But at least, it works again. It only takes soooo long.

          Show
          Miroslav Fikar added a comment - Some more: 1. [ [usemoodleroot] ] - string not defined in Administration-Modules-Blocks-Global Search 2. linux executables (pdftotext, antiword,...) are not executables - have missing X bit. It is annoying as it is not mentioned in installation instructions. 3. Typo in physical_pdf and probably elsewhere (doc,...): mtrace('Error with pdf to text converter command : exectuable not found.'); -> executable But at least, it works again. It only takes soooo long.
          Hide
          Valery Fremaux added a comment -

          This links for the X bit problem when installing

          Show
          Valery Fremaux added a comment - This links for the X bit problem when installing
          Hide
          Valery Fremaux added a comment -

          The primo-indexing execution on a loaded Moodle can be very very long indeed. There is a huge need of processing when constructing the index.

          On a recently installed, running for a month Moodle, was no long more than 40 secs !! But this IS not probably the real situation.

          Show
          Valery Fremaux added a comment - The primo-indexing execution on a loaded Moodle can be very very long indeed. There is a huge need of processing when constructing the index. On a recently installed, running for a month Moodle, was no long more than 40 secs !! But this IS not probably the real situation.
          Hide
          Miroslav Fikar added a comment -

          It takes about 12000s on two our production Moodles (cca 200 courses, 3000 users) . It would be nice if the indexer could take into the account files already indexed and not changed from the previous run.

          One more problem that still persists: Links found are not UTF8 aware and sometimes illegible with lots of accented characters (in Slovak, there are many of them).

          Show
          Miroslav Fikar added a comment - It takes about 12000s on two our production Moodles (cca 200 courses, 3000 users) . It would be nice if the indexer could take into the account files already indexed and not changed from the previous run. One more problem that still persists: Links found are not UTF8 aware and sometimes illegible with lots of accented characters (in Slovak, there are many of them).
          Hide
          Valery Fremaux added a comment -

          Miroslav, see bug MDL-14377 and resolution for the UTF8 issue in search results.

          I agree we could try to get the primo-indexing incremental, so that several successive tryouts could index all the documents. I do not know yet how to control this...

          Thanks.

          Show
          Valery Fremaux added a comment - Miroslav, see bug MDL-14377 and resolution for the UTF8 issue in search results. I agree we could try to get the primo-indexing incremental, so that several successive tryouts could index all the documents. I do not know yet how to control this... Thanks.
          Hide
          Miroslav Fikar added a comment -

          I think this bug can be closed - global search works again. Problems with non-utf8 characters still remain in latest 1.8.5, but that probably belongs elsewhere – solution of bug described in MDL-14377 did not help.

          Show
          Miroslav Fikar added a comment - I think this bug can be closed - global search works again. Problems with non-utf8 characters still remain in latest 1.8.5, but that probably belongs elsewhere – solution of bug described in MDL-14377 did not help.
          Hide
          Valery Fremaux added a comment -

          Yes I saw. this is a very odd situation, because each time we find a way to fix this UTF-8 issue and test it, it appears broken a bit later.

          I start suspecting an inconsistence somewhere between storing in index and getting back, just as if search internal indexes where toggling continuouslty between UTF-8 and ISO-8859-1 or whatever !!

          very strange behaviour ideed !!

          Show
          Valery Fremaux added a comment - Yes I saw. this is a very odd situation, because each time we find a way to fix this UTF-8 issue and test it, it appears broken a bit later. I start suspecting an inconsistence somewhere between storing in index and getting back, just as if search internal indexes where toggling continuouslty between UTF-8 and ISO-8859-1 or whatever !! very strange behaviour ideed !!
          Hide
          Valery Fremaux added a comment -

          Miroslav,

          try inverting the convertion in all xxxxxxxx_link_post_processing() by exchanging 'auto' with 'UTF-8' for all document types and tell me about results.

          Thanks.

          Show
          Valery Fremaux added a comment - Miroslav, try inverting the convertion in all xxxxxxxx_link_post_processing() by exchanging 'auto' with 'UTF-8' for all document types and tell me about results. Thanks.
          Hide
          Miroslav Fikar added a comment -

          Valery,
          I tried resource and changed
          function resource_link_post_processing($title)

          { //return mb_convert_encoding($title, 'UTF-8', 'auto'); return mb_convert_encoding($title, 'UTF-8', 'UTF-8'); }

          but it did not help. The result is the same.
          Miroslav

          Show
          Miroslav Fikar added a comment - Valery, I tried resource and changed function resource_link_post_processing($title) { //return mb_convert_encoding($title, 'UTF-8', 'auto'); return mb_convert_encoding($title, 'UTF-8', 'UTF-8'); } but it did not help. The result is the same. Miroslav
          Hide
          Petr Škoda added a comment -

          Could you please fix the merged tag in MOODLE_18_STABLE and MOODLE_19_STABLE, thanks!

          Show
          Petr Škoda added a comment - Could you please fix the merged tag in MOODLE_18_STABLE and MOODLE_19_STABLE, thanks!
          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this issue.

          We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

          If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

          Michael d;

          lqjjLKA0p6

          Show
          Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d; lqjjLKA0p6
          Hide
          Michael de Raadt added a comment -

          I'm closing this issue as it appears to have become inactive and is probably not relevant to a current supported version. If you are encountering this problem or one similar, please launch a new issue.

          Show
          Michael de Raadt added a comment - I'm closing this issue as it appears to have become inactive and is probably not relevant to a current supported version. If you are encountering this problem or one similar, please launch a new issue.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: