13 of 388 resources on modmore.com are not getting created on a clean site with Gitify build; wether using the force flag or not.

Haven't identified all missing resources yet, but it includes 101 (support home), 102, 103 (support home child weblinks) and also the web error page (46).

It doesn't seem related to the resource type (mgResource's show up just fine) and the files are present in the dump with no syntax errors that stand out. Perhaps related to a special resource status (affecting homepage, error page etc)? Or a certain flag? Or property?

Will need to do a proper diff (where's Gitify compare when you need it) to figure out which exact resources are missing, and maybe there's a hint somewhere as to what's causing it.

The general idea is for Gitify to handle serialising data stored in the MODX database to a human and machine readable format (done, Gitify load), which is then committed to a git repo (possibly along with site assets) and can be restored back to a MODX install with Gitify build.

A plugin should keep changes via the manager synced to the file system and thus git automatically. This could automatically commit and push. Changes made to the files directly should update MODX. This is done with Gitify build but would be cool to automatically do with a file watcher or something like Grunt.

Eventually, using Gitify, it should be possible to put your entire site into a git repo in minutes and inject it back into anything (such as a clean MODX install) with a simple command as well.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

The .gitify could contain a modx_version (or just version) key that contains the MODX version that it is expected to run. Then with a Gitify build or Gitify update-modx [version] it could grab that specific version and run the command line upgrade.

Thinking we can show memory usage, peak memory usage, time (in ms) and perhaps the number of created/overwritten/deleted files/objects. Could be useful when looking into optimising performance down the road, but also interesting to just see what it's up to.

This might be a new task (Gitify install-package Redactor) or part of the .gitify file where packages are defined that need to be installed/verified upon a Gitify build... or both! :D

Still trying to debug it. But it seems like children of parents are not created once i run build --force

Tested with normal resources, collection children and also taxanomies children.

I'm thinking that it would be nice if we could provide a better dynamic mechanism for resolving foreign keys. Let's say I store fictional School objects which have ClassRoom objects. Each ClassRoom has a foreign key reference "school" that contains the ID of the School object.

If the School object has another unique key, for example a string "name", we should be able of using that in the reference from the ClassRoom instead. So if we were to store it like this...

School:

id: 4
name: School ABC

ClassRoom:

id: 8
room: #14.12
school: 4

I would like to store the ClassRoom like this, instead:

ClassRoom:

id: 8
room: #14.12
school: School ABC

I think this would be possible if we add a new option to the .gitify file to indicate what relations to automatically resolve. Something like..

name: test
data_directory: _data
data:
  schools:
    class: School
    primary: name
  classrooms:
    class: ClassRoom
    primary: room
    resolve_relations: [School, OtherRelation]

The resolve_relations key would contain an array of the relations as defined in the xPDO schema/modal. It would look up the foreign and local keys and do the replacement on both extract and build.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

When I put in the command Gitify install:package without any parameters it gives me 10 random packages from the ModX repositories instead of the packages defined in .gitify.

➜  gitify_test  gitify install:package   
Searching Provider for ...
Do you want to install ReCaptchaV2 (0.9.2)? [Y/n]: n
Do you want to install Locker (0.1.0)? [Y/n]: n
Do you want to install VerticalNavigation (0.1.0)? [Y/n]: n
Do you want to install LangRouter (1.0.0)? [Y/n]: n
Do you want to install TemplateSelect (1.0.0)? [Y/n]: n
Do you want to install FileAttach (1.0.1)? [Y/n]: n
Do you want to install shopkeeper3 (3.0.0)? [Y/n]: n
Do you want to install GoogleCloudStorage (1.0.0)? [Y/n]: n
Do you want to install AddThis widget (1.1)? [Y/n]: n
Do you want to install Lunchbox (1.0.0)? [Y/n]: n
Cannot install package .

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Some settings (things with paths) shouldn't be stored, but most of them should, at least if we want to have a "build a site from a gitify template" kind of thing work.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Here's the code for using gitify within the manager. You'll need to create two system settings, gitify.path and gitify.config. Path is the path to the Gitify executable. Config is the config file location. It's possible that we could just try to find the config file and/or gitify executable, but I have no idea if/how that would work.

$gitifyPath = $modx->getOption('gitify.path');
$gitifyConfig = $modx->getOption('gitify.config');
$path = dirname($gitifyConfig) . DIRECTORY_SEPARATOR;
$error = false;

require_once $gitifyPath . '/src/Gitify.class.php';
$gitify = new Gitify();

$project = $gitify->fromYAML(file_get_contents($gitifyConfig), true);

if (!$project || !is_array($project)) {
    $error = "Gitify Error: $gitifyConfig file is not valid YAML, or is empty.\n";
    $modx->event->output($error);
    return $error;
}

// since we're not at the command line, we need to do some extra path setting here
$project['cwd'] = $path;
$project['path'] = $project['cwd'];
// need to prepend path or files are stored in the connectors directory
$project['data_directory'] = $path . $project['data_directory'];

require_once $gitifyPath . '/src/GitifyExtract.class.php';

// Don't let echos through. Well, try not to. It doesn't work though.
ob_start();
  $runner = new GitifyExtract();
  $runner->run($project);
  $return = ob_get_contents();
ob_end_flush();

if(strpos($return, 'Error') !== false) {
    $modx->event->output($return);
    return $return;    
}

return;

On OS X it runs a system-version of PHP which does not work with the PHP and MySQL shipped with MAMP. To fix it, the system PHP needs to be tricked into using the proper mysql socket.

Something like:

cd /var/mysql/
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock

http://stackoverflow.com/questions/2412009/starting-with-zend-tutorial-zend-db-adapter-throws-exception-sqlstatehy000

wipe all datas in the database for the classes included in .gititfy file before rebuild.
Actually only the content gets removed on force, but it would be great to have all classes that are defined in the file deleted before the new data gets injected. or a selective way to controll the rebuild of the database i.E. like

templates:
class: modTemplate
primary: templatename
rebuild: true

Having non-LF line endings in a gitify file results in

Could not parse Article-Template-with-Sidebar.html: Unable to parse at line 11 (near "-----").

I would expect that Gitify replaces non-supported line endings before running Gitify build.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Not sure if this is intended for some reason, but when extracting the Assigned Templates to a TV are missing.

Would be cool (and more readable) to be able to specify the category of an element by its name, rather than / in addition to its ID. Tricky part there would be "what if a category name is changed".

This does not seem to import MigX TVs during build. Can anybody else confirm this?

http://stackoverflow.com/questions/7307548/how-to-access-php-with-the-command-line-on-windows/7307581#7307581

common executable paths:

c:\php\php.exe
c:\php5\php.exe
c:\windows\php.exe
c:\program files\php\php.exe
c:\wamp\bin\php\php5\php.exe
c:\xampp\php\php.exe

Is there any documentation that would help windows users? I have it installed globally, but for example ./Gitify gives me '.' is not recognized as an internal or external command, operable program or batch file.

When you develop site from IDE, you should everytime run Gitify build for apply changes to modx. But it takes time, if it's big site - a lot of time.
By default command should build all elements from config, but we should have ability define only selected elements.
Examples:

Gitify build # all
Gitify build --snippets --chunks # only snippets and chunks
Gitify build --templates # build only template
Gitify build --system_settings # build only system settings

--param should be key from config

Referring to these as "Templates" becomes confusing when discussing Content Block Templates and MODX Templates.

It might be better to rename this to something unique. Ideas are "Presets", "Layout Sets" or "Layout Groups"

On a very large site when running gitify extract the follow error occurs:

15:25:13 - Loading modContext into contexts/...
15:25:13 - Loading content into content/...

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /Users/AdamWintle/Sites/test/core/xpdo/xpdo.class.php on line 1424

I've increased the memory_limit to 1G in the php.ini file and this is confirmed in the phpinfo file, and also tried php_value memory_limit 1G in the .htaccess file.

Running Gitify and choosing to install modx gives me this error:

Command "install-modx" is not defined.
Did you mean this?
install:modx

You probably know this, but thought id just add it here to make sure you add the right command until next update.

Since the refactor, if you do a Gitify init on a new (empty) folder, the install fails with the message:

  [InvalidArgumentException]  
  Command "install-modx" is not defined.  
  Did you mean this?                      
      install:modx

Running Gitify install:modx after that failure works.

Hi colleagues.

Now gitify can install package by name and all packages from config. But if we want can full control on packages in MODX through API, we need more commands. But now command started from word install:packages. It's not right I think. In npm and composer exists at minimum 3 commands: install, update and remove (uninstall). If we keep old syntax, we needed write gitify install:package Ace --update or gitify install:package Ace --remove. WTF? Install and --remove? :) I guess you are laughing too.

I propose to fix command syntax for package control.

gitify
    package
        install # installing of package
        remove # removing of package
        update # updating of package
        sync # sync all packages by config. Install not installed, and remove removed if needed.

If package not specified - install and remove and update all packages.
Examples:
gitify package install Ace
gitify package update Ace
gitify package remove Lingua
gitify package sync

I am ready to start with PR, but I need your's mentions.

Right now if you're in a subfolder of the MODX installation, it can't find the .gitify file. It would be nice to be able of running Gitify from a subfolder.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

it could be great to get a .gitify generated on gitify init with all settings for the actual installed packages, content and all system settings.

a nice way would be a

gitify init-fullsite

Running gitify-init on a folder with contents but no modx install resulted in a) a failed modx install and b) an empty directory.

|14:15:12| Created new Gitify project in /[...]hhh/site/
|14:15:12| > No MODX installation found. Would you like to install the latest stable MODX version? (Y/N) Y
|14:15:15| Downloading latest MODX version...
######################################################################## 100.0%
|14:17:18| Extracting zip...
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of modx.zip or
        modx.zip.zip, and cannot find modx.zip.ZIP, period.
|14:17:18| Moving unzipped files out of temporary directory...
mv: ./_data and ./_data are identical
mv: ./bootstrap and ./bootstrap are identical
mv: ./hhh and ./hhh are identical
mv: ./ideas.html and ./ideas.html are identical
mv: ./index.html and ./index.html are identical
mv: ./modx.zip and ./modx.zip are identical
rm: ./: Invalid argument

Warning: unlink(modx.zip): No such file or directory in /[...]/bin/Gitify/src/GitifyInstallMODX.class.php on line 34
|14:17:19| * Warning: could not clean up download.

Tried a couple of times. Gitify's install of MODX 2.3.2 results in manager without styling.
JS and CSS compression is off. Cleared cache dir to no avail. All perms 777.

CLImate by the PHP League seems to offer a lot of great tools to present prettier output from the command line calls, and things like the progress bar would be great to use to provide better insight into how much work is being done. http://climate.thephpleague.com/

Now when you install new modx instance you should write all params for modx every time. it will be good setup it once at .[something]rc file and use as default values for installations process.

database name (from dirname)
database user (root on local)
database password (defined password for root on local)
site url (from dirname + postfix, alroniks.com.loc or alroniks.com.dev)
lang (ru by default for me)
url path - OK
admin user (ivan for me)
admin password (once defined for local sites)
admin email (once defined for local sites)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Apparently broken on build

I defined FormIt in my .gitify but what happens is that gitify uses the modx search to find the package and then downloads the first returned package. The first returned package for a search of FormIt is FormIt2db so it downloads and installs the wrong package.

I've been pondering with 2 solutions:

• Define the author in the .gitify so the search can also check on author (Means it gets more accurate)
• Define a version although I think that's more of a different feature than the solution to this problem.

Hello Marc,

I have testet it with the modx nightly and the templates won't get exported correct.

It will only save the latest template in /templates/.yaml => the template/file name is missing

.gitify Part:
templates: class: modTemplate primary: name

Naming of other elements works as expected

When doing gitify install:package --all I would like for it to ask me per package if I want to install it like it does when you do gitify install:package NAME and if possible then have the options (Y)es, (N)o, (Y)es to (A)ll (YA) and (N)o to (A)ll (NA).

Take the files, resolve conflicts, and build a site from source with a simple php Gitify.php build.

When adding files from the filesystem you don't know the correct next ID for the element. It would be a nice feature if you're allowed to leave the ID empty and on Gitify build it would look up the correct next ID and add it automatically (to the db and the actual file).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I have noticed that the _data folder is totally insecure and if someone leaves it in their live website people could go to _data and get all the contents.

Solutions:

• Encrypt the _data folder and let gitify decrypt it with the password (As a parameter)
• Let Gitify put index.html's in every directory (not .htaccess's because NGINX doesn't work with those)

As suggested by Jason, YAML might be better as it's less verbose (no punctuation all over the place) and you don't have to escape quotes inside the values.

It would be nice to - in a similar way the content works - make use of subdirectories to store relations.

A model mpPackage with one-to-many mpVersion objects could be represented in the .gitify like this:

data:
  packages:
    class: mpPackage
    primary: name
    relations: 
       versions:
         class: mpVersion
         alias: Version 
         primary: signature

which would then result in a directory structure like this for a one-to-many relation:

_data/
  packages/
    redactor.yaml
    redactor/
      versions/
        1.5.0-pl.yaml

A one-to-one relation, for example modUser/modUserProfile, could be in the .gitify file like this:

data:
  packages:
    class: modUser
    primary: username
    relations: 
       profile:
         class: modUserProfile
         alias: Profile

As it's one-to-one, there would (ideally) be no need to specify a primary. Gitify could fetch that from the model and base it off the modUser record.

The profile file would be stored with the name from the reference ("profile") in a directory with the primary from the modUser, like so:

_data/
  users/
    marksusername.yaml
    marksusername/
      profile.yaml

Of course combinations and multiple relations need to be supported.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

https://github.com/modmore/Gitify/blob/master/src/Command/BuildCommand.php#L323

Seems to affect objects with composite keys.

Should be stored in .gitify.

When running an extract it could be useful to have a flag ignore or not extract some of the data for that particular extraction. e.g. gitify extract -content

Could later be expanded/more advanced e.g. gitify extract -contexts contextname which would then ignore that context, plus its content; or gitify extract -categories categoryname, and all elements inside that category are not extracted

Or ask what I should do

To run before doing stuff that can be potentially harmful (somewhat related to #37), Gitify backup could write a quick backup of the full database, perhaps matched with Gitify restore <backup id>

Just to make sure everything run as expected before actually changing the database.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

How to extract the Media Sources from TVs?

i've got the follow in my .gitify file so far

template_variables:
class: modTemplateVar
primary: name
template_variables_access:
class: modTemplateVarTemplate
primary: [tmplvarid, templateid]
mediasources:
class: modMediaSource
primary: name

can't find the linked mediasources

Imagine this:

data:
  content:
    type: content
  chunks:
    class: modChunk
    primary: name
    extension: .html
  users:
    class: modUser
    primary: username
    relations:
      profile: 
        alias: Profile
        class:  modUserProfile
  comments:
    class: QuipReply
    primary: [thread, subject]
    package: quip
environments:
  production:
    build_default: [content, chunks],
    extract_default: [content, users, comments]
  staging
    build_default: [content, users, comments]
    extract_default: [content, chunks]

Being able of specifying what happens with the short-hand Gitify build without specifying Gitify build content (not yet implemented) if you just want the content, depending on the environment (stored in a MODX setting), should help build clever workflows where only part of the extracted objects would need to be build again.

Right now, events aren't part of the data attached to plugins. They're pretty important to making plugins actually work.