Moodle

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

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.

This links for the X bit problem when installing

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.

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).

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.

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.

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 !!

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.

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

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

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

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.