Moodle in English: Edited changes not displaying

I have just updated to version 1.4 (latest). If I make any changes to Moodle eg. add the title of a new topic, it does not display. I need to go to Internet Explorer options, delete the Internet temporary files then refresh (F5) nthe screen to see my changes. I have tried editing on another machine and the same thing happens. Any thoughts please?

Thanks

Bruce

Average of ratings: -

Re: Edited changes not displaying

by Dennis Daniels - Thursday, 2 December 2004, 2:47 PM

My students have been reporting the same kind of problem. I try not to make too much of it in the classroom because I would have open rebellion if word got around among my students that moodle was not saving changes correctly (which happens more than I care to admit).

We're using Firefox and can report the same behavior at least four times a day, (hundreds if not thousands of alterations are being made on my Moodle classes a day) BUT changes are not being saved in 1.4.2x as dependably as I'd like. I've increased back up frequency and I'm hoping that 1.5 will be more robust.

I often wonder if writing to the database correctly is a function of the php.ini settings...

What is the recommended php.ini for moodle with HEAVY usage from three different classes of 35+ students, 105+ students at once.

Dennis

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Thursday, 2 December 2004, 4:28 PM

Umm, what Bruce is reporting and what you are reporting are two very different things.

If the changes display after a refresh, this is a common issue with web development and page caching. In IE, general settings, temporary internet files, change your caching preferences to suit your needs. Generally, check for new versions automatically works, but proxy server settings may affect this is as well. Bruce's problem might also be caused if changes have been made to page caching in the latest stable version, (I don't think they have, though folks have been posting some caching changes on the forums), but that would not have anything to do with lost data, the data would be written to the database, but the page would need to be refreshed to display the changed data.

However, if the pages change after a refresh, the data is getting into the database, and folks with properly configured browsers and proxy servers will see the changes immediately (now if you've made one of the caching hacks, then all bets are off).

If you're students are really seeing saved changes that are not inputted into the database, then refreshing the page will have no effect (the changes will still not be there no matter how often you hit F5) you've discovered a serious issue either with your set up or with Moodle. If on the other hand some students are using machines where the page caching has been set to never check for new page versions, or or only when IE starts, they might well see this behavior, though the changes will actually get into the database, it wil appear to the students that nothing changes (until they force a refresh).

If you are actually seeing apparently sucessful page edits (no error message) that don't show up even after a forced refresh, make sure MySQL is set to use my_huge.cnf and php is getting plenty of RAM (but in either case you should get an error message, not an apparently working edit that doesn't actually change things). If you have a proxy server or load balancer, make sure it is set up properly.

Please report the bug with all available information (your server type, configuration, the OS and browser versions the students are using when it happens, etc.) When you check the activity logs, does it show the students attempting to edit their posts/journals/whatever?

Where are your students seeing this? In forum posts? In journals?

Average of ratings: -

Re: Edited changes not displaying

by Bruce Riley - Friday, 3 December 2004, 9:14 AM

Hi Michael,

Thanks for the reply.

I didn't solve the refresh/editing issue. I reverted to version 1.3.3 and everything works fine again.

Bruce

Average of ratings: -

Re: Edited changes not displaying

by Dennis Daniels - Friday, 3 December 2004, 10:45 AM

Journal posts suffer data loss most often. I don't know the setting of the php.ini so I can't say how much RAM we're using.

We're using 1.4.2 (almost).

When there are more than say 30 students on at the same time our install of moodle really bogs down. More RAM of course is the first choice for fixes but again, I don't think we have access to the .ini file.

I'm leaning more and more away from journals for composition and more and more on simple text editors. The journals are becoming more a storage area rather than a composition platform.

The formatting moodle/html/ text etc all suffer from data loss at times. Students have been able to reproduce the behavior repeatedly though I can't find any real pattern in the size of the journals or the content.

best,
Dennis

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Saturday, 4 December 2004, 1:16 AM

Hi Dennis, whoever is administering your system should be able to set you php.ini and mysql cnf files for you.

AFAIK, low memory in php.ini will most likely result in slowed performance, while improper (for the load) mysql settings are more likely to result in data loss.

But you should be getting error messages on these. You might try turning debug (in admin/variables) on for a bit and asking students to send you any error messages they see, that might help track down where the problem is occuring.

I have noticed that the developers are getting a big too eager in pushing untested code into 1.4.2+, I just got burned by this yesterday and had to uninstall a block that was working fine in 1.4.2

.

It would probably be better to stick with 1.4.2 stable for the time being.

Average of ratings: -

Re: Edited changes not displaying

by Penny Leach - Saturday, 4 December 2004, 4:16 AM

Michael - did you file a bug report for it?

What exactly was the problem with the block?

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Monday, 6 December 2004, 10:14 AM

It was using the old api for sessions (it was one of our blocks, course program, so we'll update it next week.)

Since it is one of our blocks, and not a core one, I filed the bug report on our internal system, not Moodle's.

Average of ratings: -

Re: Edited changes not displaying

by Martín Langhoff - Saturday, 4 December 2004, 7:37 PM

Sorry to hear 1.4.2+ brought you trouble. It was probably me

The thing is, we do make changes to 1.4.2+, fixing bugs, getting it ready for 1.4.3. We test in many systems, and actually the code that was changed for 1.4.2+ had been on production boxes for over a month.

We did hit some issues, particularly with undocumented PHP issues with memory_limit on Win32, we fixed them a few hours after they'd been reported. There's always a tradeoff in running 1.4.2+ vs 1.4.2, probably too complex to spell out in the download page.

Now, 1.4.2+ has gotten a lot better lately (perhaps because I'm on holidays and not hacking it ;), and I would definitely recommend it. Of course, you must make a full DB backup so you can rollback if the upgrade isn't smooth.

With regards to memory_limit:
- it doesn't affect performance
- lower values will stop moodle dead on its tracks
- higher limits will conversely allow operation with larger numbers of users and courses

But the most important point is that in moodle up to (and including) 1.4.2 memory_limit is hardcoded to 64MB in setup.php, so moodle actually ignores anything set in php.ini, apache's config file, etc. 1.4.2+ and 1.5 dev include a fix that make moodle obey higher memory limits if set in php.ini, apache's conf or htaccess files. It still ignores memory_limit if it's anything lower than that.

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Saturday, 4 December 2004, 8:38 PM

The caching problems are in weblib.php:

   if ($cache) {
        @session_cache_limiter('private');
        @header('Cache-Control: private');
        @header('Pragma: ');
        @header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
        @header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
    } else {   // Do everything we can to prevent clients and proxies caching
        @header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
        @header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
        @header('Cache-Control: no-store, no-cache, must-revalidate');
        @header('Cache-Control: post-check=0, pre-check=0', false);
        @header('Pragma: no-cache');

        $meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
        $meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
    }

I do not understand it much yet, but either gmdate is not working correctly on server, or user has incorrect time setup or caching is generally messed up in client or proxy ....

could you send me links to your problematic sites by email, I need to check page headers to get more info.

skodak

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Saturday, 4 December 2004, 9:32 PM

Please see this thread describing the change in weblib.php.

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Sunday, 5 December 2004, 3:12 AM

How did that change get in to the stable branch so quickly?????

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Sunday, 5 December 2004, 3:19 AM

It happens...
STABLE are only releases, CVS is developers to work in

Please test my solution.

skodak

Average of ratings: -

Re: Edited changes not displaying

by Mike Churchward - Wednesday, 8 December 2004, 5:48 AM

Petr -

If I understand what you are saying here, I don't think you are correct. The STABLE branch is supposed to be that - stable. At least that's what it always has been.

Untested code, and code being tested should be in a developers branch. We need to have a stable branch to update sites that are updated using CVS. If we can't reliably update via CVS, we can't update sites that are customized.

mike

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Wednesday, 8 December 2004, 7:06 AM

Hi Mike.

MOODLE_14_STABLE was supposed to be stable, but it is not fully. 100% backwards compatibility is also gone. The internal changes were needed to improve security and fix some long standing problems.

I agree with you that there should be more branches, but they are not there, so the 1.4 critical fixes go directly into 14_STABLE. IMHO there could be some moving STABLE tag in stable branch to indicate the best nightly (something like in dragonflybsd).

This setup has also positive side, the problems are discovered and fixed much sooner

skodak

Average of ratings: -

Re: Edited changes not displaying

by Mike Churchward - Wednesday, 8 December 2004, 8:59 AM

Then we better think about changing the description on the downloads page, that states the STABLE branch "is probably the best one for a new server". This is not the case if the code can't be counted on to be safe for a production server.

The caching issue was one that actually rendered sites unuseable.

mike

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Wednesday, 8 December 2004, 10:11 AM

I agree completly, if experimental code is going into +, it should be labled that way (maybe just start calling it 1.4.3b rather than +)?

Average of ratings: -

Re: Edited changes not displaying

by Martin Dougiamas - Wednesday, 8 December 2004, 11:11 AM

At the time it seemed like an innocuous fix with big benefits. None of the problems came up during testing and moodle.org has been running it for over a week. I'm very sorry to find out that there have been problems after all and a return to the caching problems of old.

It's totally my fault - I should have been more cautious with this particular issue, especially since I know there is a lot of crappy browsers and proxies around. I got excited by the performance improvements and I guess I hoped the Internet had improved since 2001.

Adding more branches would just complicate things though - the current setup is fine as long as we're more careful. Apart from this caching issue I think 1.4.2+ is still a better choice than 1.4.2.

I've checked in a temporary fix to STABLE CVS to turn off caching completely until we sort this out, and I've rebuilt the nightlies to include this fix.

Average of ratings: -

Re: Edited changes not displaying

by Mike Churchward - Wednesday, 8 December 2004, 9:30 PM

Thanks Martin -

Problems happen. They'll happen again. I was only concerned because Petr's post had made it sound like the STABLE branch wasn't that anymore.

If the intent is to leave it stable, then that is good.

mike

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Thursday, 9 December 2004, 12:42 AM

IMO production sites should not be updated from CVS at all, it is better to have a test site that updates using CVS and then after several days of testing do a mirror copy to the production site.

If you have a customized site, IMO there is no "safe" way to update it from CVS.
By definition CVS is for developers, not for production site maintenance.

I agree that MOODLE_14_STABLE must be as stable as possible and if it is not I try to fix it as soon as possible.

Anybody who uses latest CVS on production server must be prepared for possible problems - he/she must monitor moodle.org, report problems, apply fixes, etc.

skodak

Average of ratings: -

Re: Edited changes not displaying

by Chardelle Busch - Thursday, 9 December 2004, 2:19 AM

Hi Petr,

I understand where you are coming from as a developer, and I think we have all learned from the 1.4.2+ snafu, so let's look at this from a user point of view.

>>>it is better to have a test site that updates using CVS and then after several days of testing do a mirror copy to the production site.<<<

Do you realize how time consuming (if not impossible) it would be to test for all contingencies in different browsers for all upgrades? This just isn't very feasible.

>>>By definition CVS is for developers, not for production site maintenance.<<<

I disagree with you here Petr. The reason we use Moodle is because we do have the capability of hacking around at the code and changing it to fit our needs. And the reason we use CVS (which is mentioned by Martin in the Documentation as a viable way to upgrade) is to make it easier to check our customized code against upgrades.

Mike and Michael are right, we do need to have a version in CVS (not necessarily the latest/nightly build) that we can count on to be stable. I know a lot of opensource programs don't offer CVS ugrading, but this is just another reason that Moodle is so special. wink

Chardelle

Average of ratings: -

Re: Edited changes not displaying

by Mike Churchward - Thursday, 9 December 2004, 2:58 AM

Hi Petr -

I'm sorry, but I can't agree with your defintion of CVS. The statement, "By definition CVS is for developers, not for production site maintenance", is simply not true.

CVS is a tool used by development houses to manage change. It is also used by IT groups to manage the roll-out of change. Its branching capability make it an ideal tool to create versions and releases that are ready for production. Many organization maintain their own CVS facility to update all of their branch facilities. You may be most familiar with it in a production environment, but that is definitely not the only way it is used.

In Moodle's case, it is the most ideal way to update customized sites. I think you'll find that most of us who do it that way, do it exactly as you describe here. It is the 'safest' and 'easiest'. What we do is roll in the new versions to our development site, check for areas where CVS couldn't resolve the differences and correct them. Then we test that everything on the development site works correctly. When satisified, the updated version can be rolled out to the production sites.

Updating Moodle from a release tar or zip is not so easy. Tar and zip do not try to merge change - they simply obliterate it.

Again, the issue is not that errors are never expected - they are. Its one of understanding the philosophy of the various branches of CVS. Martin's post has reassured us that the philosophy hasn't changed.

mike

Average of ratings: -

Re: Edited changes not displaying

by Petr Skoda - Thursday, 9 December 2004, 3:40 AM

I like these debates!! They do make people think

I was expecting that people will object to the sentence "By definition...".

You all may know I have commited very little to the CVS myself, I am only going through code and bitching about various security issues, always pushing to make big changes ASAP, complaining about coding style of other developers, etc.

Anyway I still think that maintainers need some half-stable 1.4 CVS branch to work in. And if at present there is only one 1.4 branch, it is theirs

Production sites only need some moving ULTRA_STABLE tag in this branch - I would use it too!.

IMO main purpose of this discussion is how to make 1.5 release process better, isn't it?

skodak

Average of ratings: -

1.4.2+ less stable than 1.4.2

by Martín Langhoff - Wednesday, 8 December 2004, 10:17 AM

As you know, developing -- even if it's just applying minimal bugfix patches -- is tricky, and you are likely to have your cvs tree in inconsistent states when you commit.

I find that I agree with both: we can't maintain the STABLE branch keeping it 'perfectly' stable 100% all the time. And yet, the wording in the download page encourages users to use 1.4.2+ with no mention of those risks.

People are understandably upset when they find 1.4.2+ is marginally more unstable than 1.4.2. And yet, I can't prepare 1.4.3 without committing (and possibly making mistakes in the process).

I would very much like to try labelling 1.4.2+ as 'more up to date' but also potentially less stable than 1.4.2. Target it to people actually affected by bugs in 1.4.2.

It all depends on what MD thinks of how to communicate to the potential downloader the tradeoffs between a release version and the latest stable snapshot.

Two alternatives come to mind that would allow us to keep the current download page encouraging the use of 1.4.2+:

Alternative 1 - we could run sub-branches from MOODLE_14_STABLE in a flying-fish fashion, and do small cycles of dev-freeze-test-merge. It'd mean a lot more work, but it'd mean both more freedom for us, and a more stable 1.4.2+. Drawback: getting testers for the freeze-test cycle.

Alternative 2 - we could have a floating tag, like the MERGED one, on the branch (MOODLE_14_STABLE_SNAP) and we shift the tag around as we gain confidence on the code.

Average of ratings: -

Re: 1.4.2+ less stable than 1.4.2

by Mike Churchward - Wednesday, 8 December 2004, 11:09 AM

Ideally, it would be nice to have a STABLE branch that updates with the latest release. That way, we don't have to update the tags in the production versions of the sites that we are maintaining. This would minimize the possibility of a large problem being introduced into a production system.

I think it makes sense to have a 1.4 dev branch as well, that leads into the next STABLE version.

There's no way to guarantee complete problem-free releases, but the caching issue was a biggy, and could have been avoided.

mike

Average of ratings: -

Re: 1.4.2+ less stable than 1.4.2

by W Page - Wednesday, 8 December 2004, 11:33 AM

Hello All!

The download page is clear and unclear at the same time. As a code "newbie" it would be helpful (and I am sure I am not alone) if the download page assumed that the people downloading moodle or learning how to manipulate CVS know absolutely nothing about it.

After classes are over this term. I am going to attempt to write something that explains downloading and CVS as far as Moodle is concerned for the know nothings like myself. In order to be able to do this I hope you do not mind if I "tax" all of your brains a bit because I will be asking, what may seem to many of you to be "baby questions" especially about CVS and SSH.

I feel that the experienced folk feel the instructions are clear enough. But I can tell you from a neophyte's view, it is but it isn't.

All this versioning and branching can get the head swirling.

WP1

Average of ratings: -

Re: Edited changes not displaying - need testers

by Petr Skoda - Saturday, 4 December 2004, 9:36 PM

Could you please test that

   if ($cache) {
        @session_cache_limiter('private');
        @header('Cache-Control: private');
        @header('Pragma: ');
        //@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
        //@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
    } else {

works?

Average of ratings: -

Re: Edited changes not displaying - need testers

by Petr Skoda - Sunday, 5 December 2004, 1:43 AM

I have found some interesting discussion about this topic here...

Average of ratings: -

Re: Edited changes not displaying - need testers

by Michael Penney - Tuesday, 7 December 2004, 1:52 AM

Hi Petr, this is what is in my weblib (Moodle 1.4.2+ (2004083129)):

if ($cache) {
        @session_cache_limiter('private');
        @header('Cache-Control: private');
        @header('Pragma: ');
        @header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
        @header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
    } else {

It appears the same as your solution?

But it's not working, did you mispaste the solution?

Average of ratings: -

Re: Edited changes not displaying

by Michael Penney - Monday, 6 December 2004, 10:19 AM

Hi Petr, caching appears to work normally in Netscape/Firefox in 1.4.2+, but be broken in IE6.

I noticed this while building a demo course for a presentation/training for our faculty, I had to constantly hit f5 after adding items/making changes in IE6, but when I actually gave the presentation using Netscape 7 (doing the same thing, building a course from scratch) it went off without a hitch.

I'll try your patch tomorrow and see how it works.

Average of ratings: -

Graphic mode

by Eduardo Mayorga - Friday, 3 December 2004, 5:47 PM

This sometimes happens to me, but only if I save when in "graphic mode". It saves ok when I save while in "code mode".

Regards

Eduardo

Average of ratings: -