Hand-written XML not appearing

27 views
Skip to first unread message

Colin Fredericks

unread,
Dec 7, 2017, 9:16:14 PM12/7/17
to General Open edX discussion
If you write your course via directly handling XML instead of in Studio, I've got a question that you might be able to help with.

Recently I wrote a script to create some extra course structure. (We have thousands of problems and I'm making places for them to sit.) I copied the resulting XML files into the course's folders in the appropriate places, rezipped and uploaded, and it doesn't quite show up right.

All the "structural" items show up fine. The chapter file appears appropriately as a section in Studio. I have subsections (sequentials) within it, and units (verticals) within those. However, at the component level, something fails. Neither Studio nor the live view of the course show the problems that should be sitting in those units. Studio loads for a few seconds and then shows an empty unit.

I've compared the XML output from my script to the XML generated and exported by Studio, and they look equivalent to me. I know the problem files are there and working properly, because I can get to them via XBlock URL. At this point I'm wondering if Studio has some secret list of which problems it has ok'd and which ones it hasn't. I'm stumped.

If anyone from edX is reading and wants to see this in action, the course in question is QMBio:
https://studio.edx.org/course/course-v1:HarvardX+QMB1+2T2017
Check out the bottom section on the list, named "Adaptive Problems".

Peter Pinch

unread,
Dec 8, 2017, 8:16:28 AM12/8/17
to edx-...@googlegroups.com
Hi Colin. 

Error reporting on course imports is definitely lacking. If you're up for it, I'd recommending running a devstack locally and doing a test import. You can watch the logs while the course is imported and you might see some helpful hints. 

If you have an installation of open edX set up with the sysadmin feature turned on, you can see more logging by importing via git. This is equivalent to using the import management command, but the log output is stored in mongo and there's a "git logs" page in the sysadmin panel for viewing them. 

Even then, some errors don't show up in the logs and I've sometimes had to resort to a bisect and import strategy to identify the part of the course causing issues. 

- Peter




--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/fc209309-006a-4675-9441-f4ea96704471%40googlegroups.com.

Colin Fredericks

unread,
Dec 8, 2017, 10:41:06 AM12/8/17
to edx-...@googlegroups.com
Good news: got Devstack up and running in about half an hour, which is a new record for me! Also found the source of the problem; see below.

Bad news: Man, that's a lot of warnings. Like, even before I try to import the course, just piles and piles of them. Then, once I do import the course, I end up with an import log that's 3.7 MB of just straight text. Luckily the issue was related to one of the most common warnings: a non-unique filename. The line looks like this:

2017-12-08 10:25:04,888 WARNING 14647 [xmodule.modulestore.xml] xml.py:170 - Non-unique url_name in xml.  This may break state tracking for content.  url_name=45f8da6114d14701a46d176ea8e38de1.  Content=<problem url_name="45f8da6114d14701a46d176ea8e38de1"/>

I tested by making a tiny new course with two sections, one subsection each, one unit each. One of them had a problem component. Then I exported, copied the XML for that problem into the other unit, and re-imported. The second occurrence of the component did not appear. I checked switching the order of the sections to make sure that it was the second one in the course outline (which it is) and not just the second one that I added chronologically (no). The problem is even stripped from the XML as the course is rebuilt (I checked by re-exporting).

It may also be useful to know that no component in a unit with a duplicate will show up. The presence of the duplicate makes it so that none of the others appear. This is particularly bizarre for me, because the duplicate does not appear in the XML export. If you make your XML edit, import, export, and reimport, you get a unit where the remaining components appear. If you just edit and import, no luck.

Yes, I know, there's not much of a use case for duplicate components, but there is one. I did what I did intentionally. It should break nothing. Nevertheless, only the first appearance of a particular component counts, and the rest of them are thrown out.

I'm gonna see what I can do to work around this, but I need to go be voice talent for a video now.



--
You received this message because you are subscribed to a topic in the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/C26DA522-A951-4B05-8460-6A42BBF1A507%40gmail.com.

Colin Fredericks

unread,
Dec 8, 2017, 12:45:08 PM12/8/17
to edx-...@googlegroups.com
Back from pretending to be a whiner on video to being an actual whiner in real life.

After a quick dive into the codebase, I found this:

# TODO (vshnayder): if the tag is a pointer tag, this will
# break the content because we won't have the right link.
# That's also a legitimate attempt to reuse the same content
# from multiple places.  Once we actually allow that, we'll
# need to update this to complain about non-unique names for
# definitions, but allow multiple uses.

The current implementation feels glitched, and it's clear from the notes that the original intent was to allow multiple uses of the same component. I'm going to file a bug report.

David Ormsbee

unread,
Dec 8, 2017, 1:27:18 PM12/8/17
to edx code
Hi Colin,

I agree that you've run into a bug, and that the LMS should support your use case.

DAG support in edx-platform has always been kinda spotty. They're not often used, they can't be created in Studio, and they add complexity around navigation, inheritance, access checks, and performance. Even for little things, like being able to assume that you can derive a container div id from the usage_key. I think one of the original goals was to have a stronger distinction between usages and definitions, which might have made this more straightforward -- but that's not where we are today. There's a short writeup here:


I'm not on the team that would field that ticket, but I'd appreciate it if you could please tag me on the bug you file.

Thank you.

Dave

Reply all
Reply to author
Forward
0 new messages