The MWDK is highly opinionated about what properties any given item in a qset should have, and omits properties it thinks should not belong.

This behavior ends up producing qset json files that are missing data necessary for the widget to function, which makes it difficult or impossible to test editing a currently existing widget properly.

This is being done in several widgets, let's move support into the MWDK.

const devDemo = 'demo_dev.json'
if (process.env.npm_lifecycle_script == 'webpack-dev-server') {
	options.demoPath = devDemo
}

• Add an option to getLegacyWidgetBuildConfig() named devDemoPath
• If devDemoPath set and webpack dev server in use, load the file from devDemoPath
• add a print output saying which demo.json is being loaded

It's technically possible to save and load a qset in the creator, but loading a custom qset in the player is severely limited - either demo.json would have to be changed, or an alternate demo_dev.json would have to be provided.

In addition to enabling the player to load instance qsets like the creator does, there should also be an interface (either built into the player/creator or as a separate page) to view/adjust those qsets.

Right now there's no easy way to override the rulesets for a given pattern, ex:

rules = [
    {
        test: /\.js$/,
        loader: 'some-loader'
    }
]

Overriding the default rules for the pattern matching JS files would require copying over significant chunks of the default webpack-widget config into the webpack config for an individual widget. Instead, we can create default definitions for individual rules, allowing them to be more easily overridden by widgets based on their needs, like so:

module: {
    rules: [
		rules.loaderDoNothingToJs,
		rules.loaderCompileCoffee,
	]
},

The 'Install to Docker Materia' option in the MWDK breaks if the local dev copy of Materia is using the new integrated Docker branch, since the locations of scripts/widget package storage are a little different.

Copying the format/features of the widget details page from Materia will help with checking icons, screenshots, and the features/excerpt of a widget, most of which are currently only available by looking at the files directly rather than appearing in context.

The automated docker install process broke with the renaming of images in Materia 7.0.1

Idea: add some checks to help deal with common problems when creating a new widget. These would check for all the required parts of a widget and make sure nothing is malformed - giving advice when possible.

1 minute mockup:

docker inspect <image> is now prepending host_mnt to the Source path of the mounts. This breaks the host directory path MWDK uses to install widgets.

/path/to/materia/fuel/app/tmp/widget_packages

is now

/host_mnt/path/to/materia/fuel/app/tmp/widget_packages

The express server is looking for an image called materia-web which no longer exists, causing widget installs to fail within the dev environment: it should now point to materia-web-base instead.

This needs a bit more work, but I basically needed a way to create a qset file from an instructor's document. I decided to create a task to convert a CSV into a qset yaml file, however this will only work for short answer questions, and currently is somewhat hardcoded for Flash Cards

    // Accepts a csv file and turns it into a qset yaml file.
    // Only works for Question-Answer qsets (not multiple choice)
    // Requires CSV in the following format:
    // -------------------------------------
    //  "Q","A"
    //  "Your first question","Your first answer"
    //  "Your second question","Your second answer"
    //  ...
    // -------------------------------------
    // Additionally the file should have UNIX line endings
    // (If using Sublime Text, go to View->Line Endings->Unix)
    // Reading of the CSV file can be touchy, so you may
    // want to strip out non-printable characters in the CSV
    // Sed can do this:
    //      sed 's/[^[:print:]]|[^[\n]]//g' in.csv > out.csv
    public static function convert_csv_to_qset_yaml($csv_file)
    {
        // read in CSV
        $file_area = \File::forge(['basedir' => null]);
        $csv_data = \Format::forge($file_area->read($csv_file, true), 'csv')->to_array();
        // \Cli::write(print_r($csv_data, true));

        // go through each question and convert to a qset structure
        $items = [];
        foreach($csv_data as $q)
        {
            $item = [
                'materiaType' => 'question',
                'type' => 'QA',
                'id' => 0,
                'questions' => [ ['text' => $q['Q']] ],
                'assets' => [],
                'answers' => [[
                    'value' => '100',
                    'text' => $q['A'],
                    'id' => 0
                ]]
            ];

            $item['assets'][] = false;
            $item['assets'][] = false;

            $items[] = $item;

        }

        // create yaml
        // $qset = ['items' => $items ];
        $qset = [
            'rand' => false,
            'items' => [],
            'assets' => [],
            'options' => [],
            'name' => ''
        ];
        $qset['items'][] = ['items' => $items ];
        $yaml = \Format::forge($qset)->to_yaml();

        // write yaml
        $output_file = $csv_file.'_qset.yaml';
        if (file_exists($output_file))
        {
            $output_file = $csv_file.'_'.mt_rand().'_qset.yaml';
        }
        $file_area = \File::forge(['basedir' => null]);
        if ($file_area->create(DOCROOT, $output_file, $yaml))
        {
            \Cli::write($output_file.' created', 'green');
            self::quit();
        }

        \Cli::write(print_r($yaml, true));
    }

The docker image names on Materia v5.0.0 changed and the install to materia button is broken.

The docker command to grab the container name of the webserver will be incorrect with the new docker deployment changes coming to Materia:

docker ps -a --format "{{.Image}} {{.Names}}" | grep -e ".*materia-phpfpm:.* materia-phpfpm" | head -n 1 | cut -d" " -f2

The correct search string should be the following:

docker ps -a --format "{{.Image}} {{.Names}}" | grep -e ".*materia:.* docker_app_1" | head -n 1 | cut -d" " -f2

As an example, the return value for the widget name in DevMateria for initNewWidget(arg) is in arg.general.name. In Materia it's in arg.name.

For example,
In v1.x: ucfopen/materia:app-dev docker_app_1
In v2.x: ucfopen/materia:app-dev docker-app-1

This unfortunately breaks direct widget installation (again) and will likely require adjustments to the targetImage command run by the express server.

Right now it doesn't break, but the creator page is blank. We should probably have a placeholder or duplicate the default creator from Materia.

It would be nice if DevMateria would automatically create thumbnails - that way the developer doesn't need to know the exact size.

Many of the strings in the MWDK just say 'Materia Development Kit'. Update them to the actual name.

Currently Materia will provide empty arrays for the 'features' and 'supported data' properties of a widget object if none exist for that widget - since the front end code is expecting those to be arrays, and the back end code is responsible for grabbing the relevant data from the database and formatting it properly.

The MWDK doesn't.

Currently, building the widget with github actions results in a non-fatal error:

Error: Command failed: git config user.email

In the generateWidgetHash plugin:

Looking at older builds, those fields were never populated in the build info yaml, even if the builds are marked as successful. Either the way we grab user.name and user.email needs to change, or the github actions need to be updated to accommodate the issue.

The server creates ids for questions and answers if an object looks like a question, but the MWDK doesn't.

This will cause issues when testing scoring and playing if the player relies on those IDs.

The workaround right now is to add this to the individual widget's webpack config and create a second demo.json

//override the demo with a copy that assigns ids to each question for dev purposes
let configOptions = {}
if (process.env.npm_lifecycle_script == 'webpack-dev-server') {
	configOptions.demoPath = 'devmateria_demo.json'
}
module.exports = require('materia-widget-development-kit/webpack-widget').getLegacyWidgetBuildConfig(configOptions)

Convert .md files to .html guides given a template

Example in Crossword:

1. Create markdown file in widget's src/_helper-docs/player.md
2. Create HTML template in widget's src/_helper-docs/playerTemplate.html
3. Add rules.loadGuideTemplate to webpack rules
4. Add 'guides/player.html': [__dirname + '/src/_helper-docs/playerTemplate.html'] to webpack entries (same for creator)

running yarn build will then compile the markdown into html, and insert that into the given template, then export it to build/guides/player.html

It shouldn't be super tedious to implement, namely some updates to the bundled express.js in the widget-development-kit repo to handle custom question sets. Currently, the player always loads with the demo, regardless of whether or not you're previewing a custom Qset from the creator.

The install.yaml file has a few strict requirements and is easy to mess up. It would be nice if the MDK had a yaml editor / builder, or at least a validator.

I can imagine a number of ways to go about this, perhaps it's best to split up into multiple issues. I'm open to ideas.

The player and creator are hardwired to load the demo.json qset. It would be great to be able to paste/edit other qsets and select them instead of the demo.json set.

This is a high-ish priority issue, since we're increasingly seeing dependency issues stemming from using deprecated webpack configs.

Right now, pressing the button just sits there with no visual indication it's trying.

And if the command fails for some reason, it'll just be stuck with the modal window open.

This is a deferred issue since we currently have no developers working in Windows.

This is in reference to the completed issue #715, specifically branch: "the-big-gulp" that has been merged into master most likely before this issue is looked at.

At the time of this issue's creation, the changes were QAed on Mac already.

Probably to be done in conjunction with #71

Currently the MWDK will check to see if src/_guides exists and, if so, run the creator and player guide files through a plugin to be fully generated.

This is fine most of the time, but if a widget is using the default creator it doesn't really need a creator guide - but if there isn't a creator guide, the build errors.