Moodle

Bad include reference in delete.php when activated from cron.php

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.8.5, 1.9
  • Fix Version/s: STABLE backlog
  • Component/s: Global search
  • Labels:
    None
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE

Description

Raises an include error in Lucene.php. Base inclusion path do not include Zend correct root.

Activity

Hide
Petr Škoda (skodak) added a comment -

Please stop overriding changes I do in HEAD!

Show
Petr Škoda (skodak) added a comment - Please stop overriding changes I do in HEAD!
Hide
Valery Fremaux added a comment -

Please Petr, tell me more about conflict !!

I'm still working on engine and seems we collide on that files... is an effect of unmerging my side when updating ?

Show
Valery Fremaux added a comment - Please Petr, tell me more about conflict !! I'm still working on engine and seems we collide on that files... is an effect of unmerging my side when updating ?
Hide
Petr Škoda (skodak) added a comment -

Hi!

This is what happened:
1/ I removed all php5 checks and legacy php4 stuff from HEAD about two weeks ago (including /search/ directory)
2/ you fixed some problems in STABLE and I guess you just copied the same files to HEAD a committed (without proper merging)
3/ I recommitted my changes to HEAD today (I hope I did not forget anything)

It all depends what tool you are using for branch merging. Every time when merging you must make sure that you are not overriding anybody else's changes committed to HEAD in the meantime. Some IDEs like PHPeclipse will not allow you to do this, ppl using command line tools do this more often :-| HEAD is going to diverge a lot pretty soon, unfortunately we all will have to spend much more time on merging.

Sorry for the shouting, I just wanted to get your attention
If you need more information please contact me via skype: petr.skoda

Thanks for all your work on search and everything else!!

Show
Petr Škoda (skodak) added a comment - Hi! This is what happened: 1/ I removed all php5 checks and legacy php4 stuff from HEAD about two weeks ago (including /search/ directory) 2/ you fixed some problems in STABLE and I guess you just copied the same files to HEAD a committed (without proper merging) 3/ I recommitted my changes to HEAD today (I hope I did not forget anything) It all depends what tool you are using for branch merging. Every time when merging you must make sure that you are not overriding anybody else's changes committed to HEAD in the meantime. Some IDEs like PHPeclipse will not allow you to do this, ppl using command line tools do this more often :-| HEAD is going to diverge a lot pretty soon, unfortunately we all will have to spend much more time on merging. Sorry for the shouting, I just wanted to get your attention If you need more information please contact me via skype: petr.skoda Thanks for all your work on search and everything else!!
Hide
Valery Fremaux added a comment -

I reviewed your changes in search engine files

In fact, I think the error in my process is that I have a separate development version (1.8.4) and CVS versions (from 18_STABLE to HEAD). I use a homemade tool to proceed to internal synchronization of all directories of a component, from the dev version to all other (1.9 test version, and CVS local copies). Till now I used being quite alone on search engine, not caring about internally updating back the dev copy from eventually CVS update changes. I have improved this process adding an internal script for backupdating from the CVS HEAD copy to my dev version. I noticed once that kind of divergence that was breaking back my tests (of course, i was'nt noticed about your changes )

On last version :

some changes you made broke backcompatibility with 1.8 API. I try as far as possible keeping the code as widely compatible as I can, so checked and fixed features might be backported harmlessly to prior branches.

In search/indexlib.php

If we want to keep that compatibility near §68 should call to "all moodle tables" be written :

//get all the current tables in moodle
if (!method_exists($DB, 'get_tables')){ global $db; $DB = &$db; $admin_tables = $DB->MetaTables(); } else { $admin_tables = $DB->get_tables(); }

so ensuring 1.8 and above compatibility.

Would you mind please notify on tracker before such transversal reviews so I can check that aspects and take care of your changes ?

Many thanks for your guidance.

Show
Valery Fremaux added a comment - I reviewed your changes in search engine files In fact, I think the error in my process is that I have a separate development version (1.8.4) and CVS versions (from 18_STABLE to HEAD). I use a homemade tool to proceed to internal synchronization of all directories of a component, from the dev version to all other (1.9 test version, and CVS local copies). Till now I used being quite alone on search engine, not caring about internally updating back the dev copy from eventually CVS update changes. I have improved this process adding an internal script for backupdating from the CVS HEAD copy to my dev version. I noticed once that kind of divergence that was breaking back my tests (of course, i was'nt noticed about your changes ) On last version : some changes you made broke backcompatibility with 1.8 API. I try as far as possible keeping the code as widely compatible as I can, so checked and fixed features might be backported harmlessly to prior branches. In search/indexlib.php If we want to keep that compatibility near §68 should call to "all moodle tables" be written : //get all the current tables in moodle if (!method_exists($DB, 'get_tables')){ global $db; $DB = &$db; $admin_tables = $DB->MetaTables(); } else { $admin_tables = $DB->get_tables(); } so ensuring 1.8 and above compatibility. Would you mind please notify on tracker before such transversal reviews so I can check that aspects and take care of your changes ? Many thanks for your guidance.
Hide
Petr Škoda (skodak) added a comment -

oh, this was just a start, changes in HEAD will not be backwards compatible with < 2.0, you will have to merge changes manually there
We are rewriting the datalib completely now, then comes the file handling and also later there will be database changes all over the place.

Show
Petr Škoda (skodak) added a comment - oh, this was just a start, changes in HEAD will not be backwards compatible with < 2.0, you will have to merge changes manually there We are rewriting the datalib completely now, then comes the file handling and also later there will be database changes all over the place.
Hide
Petr Škoda (skodak) added a comment -

we are very close to release, moving the target, sorry...

Show
Petr Škoda (skodak) added a comment - we are very close to release, moving the target, sorry...

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: