Remove outer directory to simplify adding redux to a theme

[alexpos]

Would be nice to simplify the directory structure of redux. We could remove the outer directory, and move README.md and redux-framework.php into the admin directory.

At the moment the directory tree looks like this:

$ tree -L 3 Redux-Framework
Redux-Framework
├── README.md
├── admin
│   ├── options
│   │   ├── css
│   │   ├── fields
│   │   ├── img
│   │   ├── js
│   │   ├── options.php
│   │   └── validation
│   └── options.php
└── redux-framework.php

To use redux in a theme you only need admin, so you need to copy that directory:

$ cd my-theme
$ cp -rv ~/other-stuff/Redux-Framework/admin .

Keeping that up-to-date is error-prone. It would be nicer to use git-submodule:

$ cd my-theme
$ git submodule add git://github.com/ghost1227/Redux-Framework/ admin

And then being able to update redux to the latest version using:

$ git submodule update

For that to work nicely, we need to drop one directory.

Further reading Git-Tools-Submodules

[denis0706]

Good idea, Alex, it should be done.

And I'm wondering, why spaces are used instead of tabs in Redux. I'm using tabs and i think it is easier to navigate and work with code with tabs, than with spaces. Also, it is saying at wp codex coding standarts to use tabs. What do you think about this?

[alexpos]

I for one had spaces in my editors config-file, but if the codex says to use tabs then I will :) I changed my settings to:

    "tab_size": 4,
    "translate_tabs_to_spaces": false,
    "trim_trailing_white_space_on_save": true

[evertiro]

I have no problem with either one, as long as it's universal. I can't stand looking at code and having indentation all over the place.

[evertiro]

Was that something like what you wanted? I did keep the file named options.php rather than theme-settings.php as I'm trying to build this around the concept that it is a universal framework, not specific to plugins OR themes.

[alexpos]

Excellent!

About the filename: what about settings.php? Now we have two files called options.php (I don't care what it's called, I just hate the idea of two files with the same name, that's just begging for support-issues)

[evertiro]

settings.php would be fine. Or we could change the inner file to something more generic, since it shouldn't need user interaction anyway.

[alexpos]

Fine by me, either way

[evertiro]

options/options.php has been renamed to options/defaults.php. With this change, I'm judging this enhancement completed.