The Matrix (Version 1.03)

[Angryboy]

Finally have n00dles' DM Matrix plugin to a reasonably stable state for beta testing, now available on GitHub.

What Is The Matrix?
The Matrix is a plugin designed to allow for easy plugin development. It allows users to implement data structures similar to simple SQL matrices and tables in order to store the data required for their plugins, and to easily generate, manage and manipulate said tables.

There are other additional features intended for easier plugin development that are included but not yet complete, such as dynamic access to the main .htaccess, quick deployment of your CSS and JS and more.

NOTE: If you are updating from a previous version of The Marix, PLEASE BACKUP YOUR DATA/OTHER/MATRIX FOLDER. If any plugin-breaking problems arise, you can revert to that backup and use the previous iteration of The Matrix.

Changelog (1.0)
- Complete overhaul moving the plugin from procedural code to Object Oriented code. The majority of the useful front-end functions still have a global equivalence for backwards compatibility (e.g. you can still use DM_query to perform queries).
- Removed field types: datepicker
- Added field types: password (encodes in sha1), tags (used xoxco's jquery plugin like shawn_a's tags plugin, bbcodeeditor (markitup), wikieditor (markitup), markdown (markitup), dropdowncustom (custom dropdown menus), users (user list), components (component list), datetimelocal (html5 as opposed to javascript) and more
- Checkbox now lets you have multiple defined options
- Multiple field properties added, including 'class' (for layout in admin panel) and default (default value)
- XML files are accessed and parsed using Array2XML and XML2Array PHP class
- Schema array has been modified (fields array is structured to show the fields then their properties, rather than being an array of the existing properties and their field names)
- Query pagination is possible
- and more...

To-Do
- Extensive documentation
- Beta testing
- Better language integration (its there, but lesser than n00dles' previous version)
- Better Regex parsing for Wiki and Markdown parsing (currently still quite broken)
- Need to fix routing (table is created; just need to enable it)

Need to add comprehensive documentation to the lineup, but for now manipulating the tables from within The Matrix plugin's interface should be fun to tinker with. Said documentation will be arriving tomorrow.

Use
- Unzip to the plugins folder and enable the plugin.
- Go to 'The Matrix' tab and start creating your tables.
- To output information from your plugin, do the following:

PHP Code:

// initialise the plugin
$var = new TheMatrix;

// query your results
$results = $var->query('SELECT * FROM foo ORDER BY id DESC');

// format the query (e.g. get the date formats correct, parse the BBCode, etc...)
$results = $var->formatQuery($results, 'foo');

// loop through the array and output as desired
foreach ($results as $result) {
  // output (e.g. echo $result['id'];)
} 


[hameau]

... password (encodes in sha1) ...

Not to detract in any way from the work you have done, but (unsalted?) SHA-1 encryption of passwords? You might as well store them in plain text, nowadays.

Now, I don't suppose anyone is likely to be using DM Matrix for national security data, but it seems a shame to have an easily fixed weakness, even in a beta version (though it is v1.0).

Lots more useful information on CrackStation.net and Defuse Security, including public domain PHP code to do it right.

[Angryboy]

Point taken. Will work on this for the next iteration.

[Bigin]

I find this concept very interesting.
Forgive my curiosity, but

The Matrix is a plugin designed to allow for easy plugin development. It allows users to implement data structures similar to simple SQL matrices and tables in order to store the data required for their plugins, and to easily generate, manage and manipulate said tables.

what advantages of this pseudo-SQL methods in comparison to, shall we say, the use of a native SQLite database for such purposes?
After all SQLite already performs this job very well, why build another one with same syntax and all the associated performance impacts?

[shawn_a]

sqllite is a php extension.

This is still flat files.

There is nothing wrong with using sha1 for passwords, but an elegant way to add salting or dcrypt would be nice. Maybe add a construct to add the password wrapper function, so user can handle it, with a default of using some kind of salt.

[Angryboy]

I find this concept very interesting.
Forgive my curiosity, but

The Matrix is a plugin designed to allow for easy plugin development. It allows users to implement data structures similar to simple SQL matrices and tables in order to store the data required for their plugins, and to easily generate, manage and manipulate said tables.

what advantages of this pseudo-SQL methods in comparison to, shall we say, the use of a native SQLite database for such purposes?
After all SQLite already performs this job very well, why build another one with same syntax and all the associated performance impacts?

n00dles implemented the SQL-like class (by bluelovers) long before I ever touched this project, so the concept should be owed to n00dles and bluelovers.

The main reasoning for using the sql4array class is that it its integration with the XML base that GetSimple uses is simple and solid. Meaning that GetSimple has a database structure that uses the same format as it always has, whilst having no dependencies on an actual SQL services. So GetSimple still has a database-less setup, but has database functionality (unless I'm mistaken on how SQLlite is integrated?)

sqllite is a php extension.

This is still flat files.

There is nothing wrong with using sha1 for passwords, but an elegant way to add salting or dcrypt would be nice. Maybe add a construct to add the password wrapper function, so user can handle it, with a default of using some kind of salt.

Elegant solutions as always, shawn :-) At the very least it is better than what I've currently implemented, so I will certainly include it for the next iteration.

[n00dles101]

yeah the original concept was to keep it simple and just use XML files without having to have dependencies on another php extension. I originally wanted to implement in sqlLite but discovered sql4array and decided to use that instead.

@angryboy... great work.. also on the docs , something I have never really had the time to do...
loving all the additions.. will sit down and have a play with it later on tonight....

[Bigin]

I think flat file may be defined very narrowly, or more broadly. But you're right, SQLite is an extension, although that is part of the PHP5 standard distribution. However, it is also the DOM or SimpleXML! :)

[shawn_a]

https://en.wikipedia.org/wiki/Flat_file_database
shrug

[evan70]

Thank You AngryBoy

Great shot again!

[Angryboy]

Changelog 1.02
- Added extra field types (dropdowncustomkey for the dropdown values corresponding to the key, not the label)
- Rudimentary language support for Italian, German and Russian (basically Google Translate copy-pasting)
- Rearranged some files and renamed some variables (e.g. schemaarray to schema) (doesn't affect end-user)
- Brought back pagination and filtering of tables on the main tables page
- Fixed some field display problems (maxlength not working before, now is)
- Fixed more strict error problems

To install, delete your matrix folder and matrix.php file from /plugins and use the new 1.02 version.

[shawn_a]

Why is "dropdowncustomkey for the dropdown values corresponding to the key, not the label" necessary.
Wouldn't a drop down with keys and no values simply use keys instead ?

Maybe I am confused how it worked before, I remember proposing key value pairs field, if no pair then keys only.

[Angryboy]

Say I create a dropdown with values, e.g.

- Value 1
- Value 2
- Value 3

If I decide to rename the values at a later date, this will not affect existing records in the corresponding table, so the values can't be updated dynamically if one decides to change the option titles. dropdowncustomkey instead uses indexes for the keys. So if you choose 'Value 1', what's saved in the database is just '0'. Hence, you can label and relabel your values at any time without worrying how it affects existing data.

Example: with CUsers, I use dropdowncustomkey for the user levels so that admins can re-title the user levels without affecting the conditionals in the coding, since the conditionals use the number keys instead of the titles of the options. So if I want something to affect only administrators, I don't need to worry about the title of the option given (which could be anything) - only the index in the dropdown.

I understand that it's a pretty hokey and unhelpful name to use, but I was running out of ways to easily distinguish between the different dropdown types. If you can provide more sensible ones, I'd change them out in a heartbeat (with backwards compatibility, of course).

*edit* I'm not exactly sure about what you mean for things working before. The original dropdown field from the procedural version of The Matrix works as it did before, where it takes values from an existing table as the labels/titles and the record IDs as the values. dropdowncustom was created to let you create options on the fly with a textarea (like Custom Fields/Special Pages) without having to build a separate table to house them. dropdowncustomkey exists for the reasons explained above.

I should have explained the difference between these dropdown types more clearly in the documentation... :S

[shawn_a]

I suggest dataviews of sorts.
https://github.com/n00dles/DM_Matrix/issues/26

But then again i honestly have not used these newer versions to see how you implemented default values.

[Angryboy]

I've responded just to ask for clarification. I'd really like to implement what you've suggested (since I've added some field types that others have suggested without knowing - the tags are one), but the idea just needs to be spelled out to me some more.

Default values are now a field property like the 'name' or 'label'. It has its own input in the 'fields' section of the table view and said value is used in field inputs when no value is provided and is used for queries if a record doesn't have that field set.

[n00dles101]

for my new code I check whether the array is associative or not and build the dropdown using it.
Otherwise the dropdown uses the labels only

Code:

* @param array $arr Array to check
    * @return boolean True is array is associative
    */
    public static function isAssoc($arr){
        return array_keys($arr) !== range(0, count($arr) - 1);
    }

Then build the dropdown with

Code:

if (!Arr::isAssoc($options)){
                    foreach($options as $item){
                        $this->value .= '        <option value="'.($item).'"';
                        if (($value)==($item)) $this->value .= " selected ";
                        $this->value .='>'.$item.'</option>';    
                    }
                } else {

                    foreach($options as $item=>$value2){
                        $this->value .= '        <option value="'.($item).'"';
                        if (($value)==($item)) $this->value .= " selected ";
                        $this->value .='>'.$value2.'</option>';    
                    }
                }

sorry its copy/pasted from new code, but you get the idea...

[shawn_a]

I have used other products that do a [key]\n or [key],[value]\n in a textarea to configure combos.
And a third for default [key],[value],[default] or sumtin like that.

[Angryboy]

So you're basically asking for custom associative keys to be allowed by to the dropdowncustomkey field? If so, I can work on that now, actually.

[shawn_a]

I have no idea what the current syntax is, is it documented somewhere ?
I just see a textfield under it.
Where do you currently put the options ?

I was actually just thinking about how to have less datatypes that do the same thing by using a combined syntax and a code block like n000dles just posted.

[Angryboy]

matrix/php/var/fields.php has an array with all of the field types and field properties.
matrix/php/classes/matrix.php on line 1209 (at the time of speaking, in version 1.02) has the displayField method, showing the input for each field).

[shawn_a]

What is this new code you speak of n00dles ?

[n00dles101]

For ogma, Which is based on the original matrix and rewritten from scratch. Before angryboy started work on this one.....

[Angryboy]

Changelog 1.03
- Added labels to field configuration to make it much easier to understand what the fields do
- Field types have been divided into 'type' and 'mask' for easier categorization - e.g. bbcodeeditor is now considered 'textarea' with mask 'bbcode'
- WYSIWYG editor has been changed from CKEditor to something more lightweight
- Code Editor has been changed from CodeMirror to something more lightweight yet more feature rich
- Javascript files renamed and unnecessary ones deleted
- '+Options' button when adding/editing fields now only comes up when the metadatawindow has fields in it
- And more

To install, delete your matrix folder and matrix.php file from /plugins and use the new 1.03 version.

[RobA]

Is there a tutorial for creating a plugin that uses The Matrix?

-Rob A>

[Angryboy]

Not a full one yet. Just bits and pieces on the wiki. Eventually one will be written...I can't say when, though.