如何将Moodle核心/lib/coursecatlib.php的修改迁移至独立插件？

Absolutely! Turning your core /lib/coursecatlib.php modifications into a standalone Moodle plugin isn’t just possible—it’s the smart move to avoid the headache of re-applying hacks every time you upgrade Moodle. Let’s break down how to do this properly:

Step 1: Audit Your Core Changes #

First, you need to map exactly what your edits to coursecatlib.php are doing. Ask yourself:

• Did you modify methods in the coursecat (or core_course_category) class? For example, tweaking how courses are fetched in get_courses()?
• Are you adding new logic like custom category sorting or permission checks?
• Did you alter how course categories are rendered in the UI?
• Or are you adding new fields/metadata to course categories?

This clarity will help you pick the right plugin type and approach.

Step 2: Pick the Right Plugin Type #

Moodle’s plugin ecosystem has options tailored to different use cases:

• Local Plugins: The most flexible choice for most custom logic. If your changes add new functionality, override core methods, or hook into course category workflows, a local plugin (e.g., local_coursecat_custom) is your best bet.
• Theme Plugins: If your edits only affect the UI (like changing how category lists look or adding HTML elements), move that code to your theme’s templates or custom renderer.
• Event Observers: If your code triggers actions when course categories are created/updated/deleted, build an observer plugin to listen for those core events and run your logic.
• Class Overrides: For modifying existing core_course_category class behavior, you can override the core class via a plugin (advanced, but effective for method-level changes).

Step 3: Migrate Your Code to the Plugin #

Let’s walk through common scenarios with concrete examples:

Scenario 1: Overriding a core_course_category Method #

If you modified a method like get_courses():

1. Create a local plugin folder (local/coursecat_custom).
2. Add a classes/coursecat.php file with your overridden class:

namespace local_coursecat_custom;

class coursecat extends \core_course_category {
    // Override the method you edited in core
    public function get_courses($options = array()) {
        // Your custom logic here
        // Call the parent method if you need to retain default behavior:
        // $courses = parent::get_courses($options);
        // Modify $courses as needed
        // return $courses;
    }
}

3. Register the override in classes/autoload.php:

$classmap = array(
    'core_course_category' => __DIR__ . '/coursecat.php',
);

return $classmap;

Scenario 2: Customizing Category UI Rendering #

If you changed how categories are displayed:

1. In your local plugin, create a classes/renderer.php file to override the core course renderer:

namespace local_coursecat_custom;

class renderer extends \core_course_renderer {
    public function course_category($category, $depth = 0, $options = array()) {
        // Get the default output first
        $output = parent::course_category($category, $depth, $options);
        // Add your custom content
        $output .= '<div class="custom-category-note">Your extra category info here</div>';
        return $output;
    }
}

2. Register the renderer in your plugin’s config.php:

$THEME->renderer_overrides = array(
    'core_course_renderer' => 'local_coursecat_custom\renderer',
);

Scenario 3: Adding Custom Category Fields #

If you added new metadata fields to categories:

• For simple use cases, use Moodle’s built-in Custom Fields (Site administration > Courses > Custom fields) to add fields without code.
• For complex logic (like validation or custom storage), build a local plugin to handle field saving, display, and validation using Moodle’s custom field APIs.

Step 4: Test Thoroughly #

• Restore your original coursecatlib.php file first (make sure you have a backup of your changes!).
• Install your plugin and test every feature that relied on the core hack—ensure it behaves exactly as before.
• Test a Moodle upgrade (even a minor version) to confirm your plugin doesn’t break compatibility.

Pro Tips #

• Ditch Core Hacks for Good: Plugins keep your customizations isolated, so you won’t have to re-edit core files every time Moodle updates.
• Stick to Moodle APIs: Avoid using deprecated functions or direct database calls—use official Moodle APIs to ensure long-term compatibility.
• Document Your Plugin: Add a README file explaining what it does, how to install it, and any dependencies.

内容的提问来源于stack exchange，提问作者ensiferum