We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 44007
    • 15 Posts
    It's a question for BobRay really, but also in case others find the same happening. I am pretty sure I've RTFM and followed things to the letter but there's still plenty scope for it being a case of user error.

    1. I have created my own project and edited the config file in /core/components/mycomponent/_build/config/
    2. Bootstrap the new project. All looks good.
    3. Hack around with the code generated in /assets/mycomponents/newproject/. I'm not using mgr to edit anything at this stage.

    I'm happy so far. Chunks, snippets etc etc are all in place and when I build my package they're all there (and install as I'd expect).

    4. I then decide to use install.options to allow an API key to be added during installation, and add the form HTML to user.input.php
    5. Specify a (default) resolver in project config, bootstrap again. Add my code to the resolver that's created.

    However, when I build my project now, the resolver isn't added to the transport package (I only worked this out after my resolver code wasn't being run, took a while!). The instructions say not to mess with the config file that's placed in /assets/mycomponents/newproject/_build/config/ so I haven't but I noticed that it hadn't been updated. In the name of experimentation, I renamed it to something else, ran boostrap again and it re-generated. A build of the project now includes the resolvers I later added.

    I'm happy enough that I can get round it but if I've misunderstood part of the process, pointers would be grateful.

    Thank you, BobRay for what is an incredible amount of work and a huge timesaver. I'd been put off creating packages for MODX for so long, I wish I'd looked at this years ago.


    This question has been answered by BobRay. See the first response.

    • discuss.answer
      • 3749
      • 24,544 Posts
      Hi Andy,

      Thanks for the kind words. I don't think anyone would believe me if I mentioned how many hours it took to create MyComponent. wink

      Bootstrap is guaranteed to be non-destructive, which means it won't ever update files or objects that already exist. If you add stuff to the config file, bootstrap will create new files (and objects in MODX) that aren't there already. Renaming the file let bootstrap create it (because there was no existing file), but it's not really the correct method.

      Export Objects is meant to update the object source files, and more to the point, update all the files used in the build. Export Objects, with a few exceptions, bases the build files on what already exists in the Manager and on the disk, rather than what's in the config file. Export Objects always copies the master config file (the one you edit) to the local directory, so any new builds will use the new config file. If you don't run Export Objects, the local config file is never updated.

      I work on the disk for almost everything. The one thing you always want to do is either have everything on the disk ahead of what's in MODX, or vice versa. It's a potential catastrophe do some work on the disk, and then some work on other objects in the Manager. You have to do some cutting and pasting before performing an action in MyComponent to prevent losing some of your work .

      So, to add a new capability (chunk, template, sub-package, etc.), what I do is -- first synchronize the disk files with what's in the Manager by doing step one or step two below:

      1. If the disk files are ahead of what's in MODX, run Import Objects and then Export Objects.

      2. If the stuff in the Manager is ahead, run Export Objects.

      3. (optionally commit to git).

      4. Modify the config file to add your new object or file

      5. Run Bootstrap

      6. Edit the new objects or files as needed

      7. If you did the work in the Manager, run Export Objects

      8. If you did the work on disk, run Import Objects, then Export Objects

      I hope that all makes sense.
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 44007
        • 15 Posts
        Haha no, I'd believe you; backed up by having a root through the GitHub repo to see if I could work out where and how resolvers were packaged!

        Since I've been working exclusively off disk, I didn't appreciate that Import/Export objects would still come into it. I've been using this MODX installation just for development of the package, and testing it on a separate installation. Makes sense now though, every day a school day.

        Thank you, again.