Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-14325

Global search doesn't work in 1.8.5

    Details

    • Type: Bug
    • Status: Closed
    • Priority: 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

      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

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            vf 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
            vf 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
            fikar 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
            fikar 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
            vf Valery Fremaux added a comment -

            This links for the X bit problem when installing

            Show
            vf Valery Fremaux added a comment - This links for the X bit problem when installing
            Hide
            vf 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
            vf 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
            fikar 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
            fikar 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
            vf 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
            vf 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
            fikar 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
            fikar 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
            vf 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
            vf 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
            vf 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
            vf 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
            fikar 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
            fikar 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
            skodak Petr Skoda added a comment -

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

            Show
            skodak Petr Skoda added a comment - Could you please fix the merged tag in MOODLE_18_STABLE and MOODLE_19_STABLE, thanks!
            Hide
            salvetore 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
            salvetore 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
            salvetore 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
            salvetore 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: