Category: Best Practices

AI Subsystem in Moodle 4.5

One of the many new features in Moodle 4.5 is the AI Subsystem. Given the buzz around AI development and the wild pace of change with LLM based tools it isn’t a surprise to see the beginnings of AI incorporated into Moodle. At the Lafeyette College-hosted Winter Hack/Doc 2025 I spent some time exploring the functionality. The development task for AI was documented by Moodle as “AI subsystem MVP”. The functionality released in Moodle 4.5 consists of three primary user facing interfaces into AI tools, “Generate Text”, “Generate Image,” and “Summarize”.

AI Implementation

For the new features to be available an admin needs to visit the AI section of the Site Administration menu. In Moodle 4.5, two AI providers are supported, OpenAI and AzureAI. Without a valid configuration, UI elements regarding AI are not shown.

AI Provider Configuration

The configuration for the AI providers is broken down into two areas. The first involves configuring the API keys and other requirements for your connection.

Image of the configuration options for Azure AI inside Moodle 4.5 the options. The Options are: Azure AI API Key, Azure AI API Endpoint, a checkbox to enable/disable a site-wide rate limit (default: off), the field for the maximum site wide requests per hour (default if enabled: 100), a checkbox to enable/disable user limits (default: off), and the field for the user requests per hour limit (default if enabled: 10).
Azure AI Configuration options

You can enable a maximum number of requests per person and/or at the server level for communications with the AI provider.

Below the AI provider configuration there are three configurations for each of the user facing interfaces. In addition to individual toggles these include configuration of API versions (these vary slightly between providers, OpenAI screenshot provided below), but also contain an area for a set of System Instructions. These are instructions passed along to the AI Model prior to the content of the user’s prompt:

Screenshot of the configuration of the Generate Text for ChatGPT under Moodle 4.5 showing the 3 configuration options. Those options are: AI model, the AI endpoint and System Instructions. The default for system instructions are: "You will receive a text input from the user. Your task is to generate text based on their request. Follow these important instructions: 1. Return the summary in plain text only. 2. Do not include any markdown formatting, greetings, or platitudes."
Generate Text Settings

AI Placement Configuration

Located below the provider configuration are AI Placement configurations. These allow for UI based control over enabling/disabling of AI elements in the text editor (generate text/image) and course pages (summarize).

User Experience with AI Tools enabled in Moodle

The “universal” sparkle/diamonds symbol indicating AI are added to the toolbar when Text Editor placement is enabled (and an API provider is configured). In further confirmation that Atto editor is being deprecated the Atto editor doesn’t have the AI buttons. Under the sparkles the user experiences two options if everything is enabled: Generate Text, Generate Image. If one or the other is disabled, the sparkles are replaced by a pictogram indicating the one remaining enabled option instead of pure sparkles.

The first time a user first clicks any of the AI tool options, an AI Usage Policy appears. If the user declines, the AI dialog closes. If they accept they are allowed to proceed into the tool.

Screen shot of the AI policy default settings in Moodle 4.5: <h4><strong>Welcome to the new AI feature!</strong></h4> <p>This Artificial Intelligence (AI) feature is based solely on external Large Language Models (LLM) to improve your learning and teaching experience. Before you start using these AI services, please read this usage policy.</p> <h4><strong>Accuracy of AI-generated content</strong></h4> <p>AI can give useful suggestions and information, but its accuracy may vary. You should always double-check the information provided to make sure it's accurate, complete, and suitable for your specific situation.</p> <h4><strong>How your data is processed</strong></h4> <p>This AI feature uses external Large Language Models (LLM). If you use this feature, any information or personal data you share will be handled according to the privacy policy of those LLMs. We recommend that you read their privacy policy to understand how they will handle your data. Additionally, a record of your interactions with the AI features may be saved in this site.</p> <p>If you have questions about how your data is processed, please check with your teachers or learning organisation.</p> <p>By continuing, you acknowledge that you understand and agree to this policy.</p>

The policy text lives in the language pack under core > ai.php. It’s named “userpolicy”.

The summarize button appears in lots of places by default but the portion of the page that it sends to the AI provider for summary doesn’t always make sense. For example, on this quiz page with a description of the assignment (well, sort of) the student doesn’t get any useful information from the quiz description that the instructor “provided”.

A bad AI summary of a Quiz

Limiting AI availability inside Moodle to specific courses

In the event that your institution has the appropriate subscriptions and you think someone might need to access the functionality in Moodle but you don’t want to make it available to your whole community we suggest the following implementation.

Set the following permissions to PREVENT at the site level for the teacher, student, and other roles at your institution that shouldn’t see the tools:

  • aiplacement/courseassist:summarise_text: controls access to the Summarize text button
  • aiplacement/editor:generate_text: Controls access to the generate text button in the TinyMCE interface
  • aiplacement/editor:generate_image: Controls access to the generate image button in the TinyMCE interface

Once they are set to prevent you can override these capabilities to ALLOW at the course (instructor capability under Participants -> Permissions) or category level where appropriate.

Note: CLAMP didn’t have access to both providers so I can’t provide insight into what happens if both providers are enabled. Do users get two “generate image buttons/summarize/etc” or a choice after clicking the button? If you experiment with this let us know!

Image redaction and orientation in Moodle 4.5

Moodle 4.5 introduces many new features which we’ll be covering in the forthcoming report out of the 2025 Winter Hack/Doc Fest. Here, I’m going to highlight one in particular: image redaction. This is a new security feature that will automatically strip out geolocation data from uploaded images. It’s important that you configure it correctly, because at the moment there’s a bug that could cause many images that have a portrait orientation to display in landscape.

Exif and GPS data

Exif is a metadata standard implemented by images. You can specify a dizzying array of information, but we’re concerned here with just a few fields: geographic coordinates, image width and height, and orientation. When smartphones take images they include latitude and longitude unless you disable that behavior on your phone. For example, here’s a photo I took from the rear of the California Zephyr in 2018:

Railroad tracks disappear into the horizonMy notes say that I took it in Utah. The encoded GPS information says that I took in near Mt. Elliott, about twenty miles northwest of Green River. Here’s what that data looks like:

GPS Altitude  : 1419 m Above Sea Level
GPS Date/Time : 2018:10:21 00:14:56Z
GPS Latitude  : 39 deg 9' 39.62" N
GPS Longitude : 110 deg 20' 33.62" W
GPS Position  : 39 deg 9' 39.62" N, 110 deg 20' 33.62" W

This is pretty useful for knowing where I when I took this! This might be less useful if I’d taken this picture somewhere private–say from a dorm room when I’m uploading an assignment to Moodle. Location data can be a major privacy risk if disclosed inadvertently.

Exif and Orientation

Another use of Exif data is to store the width and height of the image and its orientation (portrait or landscape). Some smartphones, particularly the iPhones we tested at Hack/Doc, store all images in the landscape format but then set the orientation to indicate that they should be displayed in portrait mode:

Orientation  : Rotate 90 CW
Image Width  : 5712
Image Height : 4284
Image Size   : 5712x4284

An image with the width greater than the height would imply landscape except that Orientation is set to “Rotate 90 CW”: rotate ninety degrees clockwise. When you view that image, you’ll see it in portrait mode so long as the browser or image software respects that Exif data.

Redaction

Moodle 4.5 adds a new feature called EXIF remover to strip out GPS information. It’s located in Site administration > Server > File redaction > EXIF remover. If you’re installing a new 4.5 instance it’s enabled by default; if you’re upgrading an existing instance to Moodle 4.5 it’s off by default and you have to choose to turn it on. By default, it uses the GD library to reprocess the image. GD doesn’t have special features for managing Exif metadata; GD will remove all fields, including Orientation! That’s undesirable at best, and probably a bug (see MDL-84128).

Moodle HQ doesn’t recommend running this way and CLAMP doesn’t either. The recommended approach is to install exiftool on your server and configure your Moodle instance to use it. Exiftool is a common command-line application; it’s available for Windows and Mac and most Linux distributions. I used it to extract the Exif examples in this post. Once you’ve installed it (or your hosting provider has), you need to configure the path in Site administration. Below is an example of a working configuration:

Moodle configuration page. Enable EXIF remover is checked. Path to ExifTool is set to "/usr/bin/exiftool". The EXIF tags that will be removed is set to GPS only.

Exiftool will output a new image with the given Exif tags removed but won’t change anything else. I assume that the GD option was provided as a fallback since it doesn’t require new external tools or new PHP libraries, but I don’t think it should be enabled by default because of the real possibility that it breaks image uploads from smartphones.

TeXshop icon

Making LaTeX accessible

The first question most people ask is, “Isn’t there an export option to make PDFs created in LaTeX accessible?” It may be theoretically possible, but no one has developed or maintained a package that does it successfully. The main issue is that LaTeX-to-PDF exports have equations and graphs, etc, exported as images without alt-text. In other words, these PDFs are inaccessible.

So the alternatives are to:

Our research here at Swarthmore has led us to find outdated packages for LaTeX that do not successfully export to an accessible PDF. Many were developed by folks at universities in search of a solution.

What we recommend, instead, is to prepare LaTeX for export to HTML.

Resources needed

Prepare LaTeX for export to HTML

In order to achieve 99% accessibility with any output, the easiest answer is to edit the source document. In this case, we will need to edit our LaTeX code so that the .html meets accessibility best practices.

  • Insert title in preamble metadata: \title{_} ;
  • Insert sections in document body: \section{_}, etc ;
  • Use \enumerate{_} \item \item … \end{enumerate} for numbered lists;
  • Use \itemize{_} \item \item … \end{itemize} for bulleted or unordered lists;
  • Use only one font attribute for emphasis.
  • Use all caps and italics sparingly.
  • Use color contrast according to WCAG compliance. WebAIM: Contrast Checker.
  • Use tables only for tabular information.
  • Use alt text for images, diagrams, etc. Images Tutorial | Web Accessibility Initiative (WAI) | W3C.

Export the LaTeX to HTML

  1. Download and install PANDOC to your computer / local environment if you haven’t already.
  2. Review LaTeX to HTML via PANDOC | Dan W. Joyce to understand what the codes mean.
  3. Open your Command Line Interface (CLI).
  4. Copy and paste the following command at the prompt: pandoc --shift-heading-level-by=1 --mathjax -f latex -t html -s -o <file>.html <file>.tex.

What does this have to do with Moodle?

When we discuss best practices in accessibility, we talk about

  • allowing an end user to choose their preference.
  • maintaining accessibility in the source document.

In the case of LaTeX, we have had students prefer to read the .tex file exactly as .tex because that is easier for them than the inaccessible PDF. Might we find ways to have Moodle export a .tex file to .html or .pdf or something else in some quick and easy way?

For now, we instruct faculty on how to post .html files on their Moodle sites.

Posting HTML files to Moodle

These are the current steps to post a remediated HTML to Moodle, as given to instructors at Swarthmore, where we post remediated files to Google Drive:

When downloading a folder from Google drive, it becomes a .zip file. You may choose to download each folder for your remediations and then directly upload them to your Moodle course page. Here’s how to do that.

  1. Open the Moodle course in which you’d like to place the .html.
  2. Enable Edit mode.
  3. Add an activity or resource.
  4. Choose File.
  5. Fill out the required field: Name.
  6. Choose the .zip file that contains the whole folder with everything in it.
  7. Once it’s showing in the “Select files” area, select the folder.
  8. In the dialog box that pops up, choose Unzip.
  9. You will likely see:
    • an images folder, if there are images
    • the .html or .xhtml file.
    • the original .zip file.
  10. Delete the .zip file.
  11. Select the .html or .xhtml file.
  12. Choose Set main file.
  13. Choose Save and return to course.

Some professors choose to put the .html, .tex, and keep the .pdf so students can choose from the .html, .tex, and the .pdf files. Others replace .pdfs with the .html altogether. HTML files, when done correctly, are generally more accessible than .pdfs.

For more information on posting displaying a website index page or .html to your Moodle site, refer to Moodle’s File Resource Settings page.

How you can help

  • Can you think of ways to streamline this process?
  • Can you think of ways to have Moodle export any file, including .tex or .docx or .pptx to .html or .pdf or something else in some quick and easy way? It could be by the end user (student, presumably) or the faculty.
  • Are you aware of other ways to handle STEM in an accessible manner?
  • Learn and implement accessibility practices every day!

We discussed a few of these at Hack/Doc in June and feel the project is just beginning.

Reach out to accessibility@swarthmore.edu if you have thoughts about this or other accessible STEM topics.

Additional, potentially helpful resources

Acknowledgements

The folks below contributed in various ways to our thought process about accessible STEM, particularly LaTeX.

Using the Moodle wiki to create a commonplace book

Professor Chris Phillips, Lafayette College
Course: Inventing America: English 332/American Studies 362

Commonplace books were popular in the 18th century, but go back to the Renaissance. You read something; you want to keep it in mind; instead of memorizing it you write it down so you don’t have to remember it. This is something Jefferson used to keep track of his speeches; this is something that a number of writers and readers during the 18th century used also to communicate. You write down something, you write a comment, you take it to a friend’s house and they copy down things they think are interesting, and they write a response in your book. It’s kind of like Facebook groups in 18th-century form.

In class, I wanted students to get a sense of what this type of text world was like. So they kept commonplace books throughout the semester. The students kept notes of their reading; they would write responses to it, they would add in different things from our trips. Some of them would cut out pieces of brochures and glue them in, some would write long reflections, and then they would write responses to each other.

Toward the end of the course, I wanted them to think about the other dynamic of commonplace books which is that a lot of times when say Jefferson was putting a speech together or when someone like Elizabeth Graeme Ferguson wanted to publish in a magazine, you’d have to take something out of this manuscript world and get it into another medium. So the students constructed a course anthology, and it was up to them to decide the medium, and they wanted to use a wiki.

They thought this was the best way to publish a commonplace book that still looked like what an 18th century commonplace book might look like, just no longer in manuscript form. So students entered excerpts from their books. These are quotations, reflections, and responses to each other. Someone added a link to a museum we went to as a way of adding a memento rather than scrapbooking it in.

The benefits of using the wiki were that it was simple to set up, but it also opened up interesting discussions about changes between media, changes between anthologizing practices and got us into questions about what it means to work in a system where you don’t keep track of intellectual property. Nothing is attributed in the anthology, and the students wanted it this way. Commonplace books were about collective authorship so this was our chance to use some of the newest technology to construct one of the oldest types of media they’ve been involved in.

Sample commonplace book in wiki
Sample commonplace book in wiki