We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39932
    • 483 Posts
    So, I've installed PackMan, read the documentation. Now, I have several System Settings that I need to export, as well. It doesn't look as if PackMan does this. Further, the tutorial on creating an Extra also does not seem to approach this topic. How do I add System Settings (if they are not added)?

    Also, these plugins are compatible with each other and some utilize the same System Settings, so I probably need them in the same namespace (do I?). Can this be done with multiple packages? Can it be done in such a way that I don't overwrite the System Settings that are added by previous packages (if not, it is okay, I just need to know for my documentation)? [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]
      Website: Extended Dialog Development Blog: on Extended Dialog
      Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
      Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

      Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
      • 39932
      • 483 Posts
      OK, so with regard to adding the System Settings, it looks like I would add them to the namespace.vehicle?

      Regarding using the same namespace, I could simply change the namespace in the manifest and vehicles. My concern here is that I don't want to overwrite the previous namespaces settings if I can avoid it.
        Website: Extended Dialog Development Blog: on Extended Dialog
        Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
        Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

        Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
        • 28042 ☆ A M B ☆
        • 24,524 Posts
        I'm not real sure if PackMan is still recommended; it hasn't been worked on for over a year, and a lot has changed in Revo since then.
          Studying MODX in the desert - http://sottwell.com
          Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
          Join the Slack Community - http://modx.org
          • 39932
          • 483 Posts
          That's a bleeding shame. I want to put my Template Switching plugin up there. I also added a Snippet, so it could be run on a Resource-by-Resource basis, if the developer so chooses. sad

          I figured that one would be the easiest, since it requires so few configuration settings. (just one)

          Note: It seems to create the Transport Package okay...
            Website: Extended Dialog Development Blog: on Extended Dialog
            Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
            Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

            Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
            • 28042 ☆ A M B ☆
            • 24,524 Posts
            Go ahead and give it a try, I just seem to remember something about it not being updated. You might also find this interesting. http://bobsguides.com/mycomponent-tutorial.html
              Studying MODX in the desert - http://sottwell.com
              Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
              Join the Slack Community - http://modx.org
              • 4172
              • 5,888 Posts
              PackMan should still work well.
              I'm a bit lazy and use PackMan too, for example for putting MIGX - packages together.

              would be nice, if someone would extend it a bit, for example for adding actions and menues .
                -------------------------------

                you can buy me a beer, if you like MIGX

                http://webcmsolutions.de/migx.html

                Thanks!
                • 39932
                • 483 Posts
                I'm already looking at doing just that. Now that I have some free time, anyway. It may take a while... but now the goal is to use PackMan to make PackMan. It will give me the experience I need to build transport packages anyway. (It looks like I need to build several, as my tutorials are quite simple, but many of the users of MODx are not technical and may get overwhelmed).

                The build scripting and vehicles don't look that complex themselves. It's basically externally mutated PHP. I used to write a fair amount of self-mutating PHP (super fast dataloads!). There are just a lot of them....
                  Website: Extended Dialog Development Blog: on Extended Dialog
                  Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
                  Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

                  Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
                  • 3749
                  • 24,544 Posts
                  The next version of MyComponent will add System Settings to a package for you. In fact, it will do everything but cook you breakfast. wink

                  PackMan is a great tool, but it is not meant to handle complex packages and if you intend to work on new releases for an extra down the road, you will definitely want a real build script.

                  I'm refactoring MyComponent pretty much from the ground up and it's not even really an alpha version (the directories will be reorganized). It's also pretty severe about how a project must be organized.

                  That said, you can actually use it to create a build script that creates and sets new System Settings and handles pretty much everything but users and security stuff.

                  You can clone or download from here: https://github.com/BobRay/MyComponent/tree/refactor.

                  There's no tutorial yet, but here (I think) is what you need to know (off the top of my head, so probably not completely correct):

                  (Replace myproject with the name of your extra.)

                  1. Create a directory in your MODX assets folder called mycomponents (note the 's').

                  2. Get the package from GitHub -- you should then have /assets/mycomponents/mycomponent/ with _build under that. (Be sure you're on the 'refactor' branch at GitHub.)

                  3. In the _build/utilities/config directory, duplicate the example.config.php file, call it myproject.config.php

                  4. In the _build directory, edit the build.config.php file. Change line 10 to
                  $configFileName = 'myproject.config.php

                  5. Load up myproject.config.php file from step three. This is your project config file and the only thing you need to mess in MyComponent from here on). Edit the crap out of it. It basically specifies everything you want in the package. The comments in the file should tell you what goes where. I'd avoid having any static elements with this version.

                  At this point, you're ready to rock and roll.

                  6. Load the file bootstrap.php in the _build directory. Run it. It should be completely non-destructive. In theory, it won't touch existing files or MODX objects. When you're done, you'll have a hefty project directory: assets/mycomponents/myproject containing a universal build file and most of the files you'll need. the Bootstrap script will also create dummy versions of all the objects if they don't exist already.

                  7. Go into MODX and check everything out. Create properties for any objects that need them, set the fields of System Settings (important: set the namespace to the lowercase category of your project). Get everything working if it isn't already.

                  8. Double-check the 'process' element near the end of the project config file to make sure it lists all your objects.

                  9. In the MyComponent/_build directory, find the exportobjects.php file. Run it.

                  10. Have a beer.

                  11. Cross your fingers and run the build.transport.php file in the mycomponent/_build directory. If everything worked, you'll get no error messages and will see a package in the core/packages directory myproject-xx-xx.build.transport.zip that can be installed on any MODX site.

                  If it's a package for release, you'll want to edit the files in the docs directory. Planned utilities will let you check the the completeness of your properties files and create a properties table for your documentation). You'll also want to create language strings for the project (the lexiconhelper utility isn't finished yet -- it will help a lot with that).

                  Let me know if you run into trouble.

                  ------------------------------------------------------------------------------------------
                  PLEASE, PLEASE specify the version of MODX you are using.
                  MODX info for everyone: http://bobsguides.com/modx.html



                  [ed. note: BobRay last edited this post 14 years, 1 month ago.]
                    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
                    • 39932
                    • 483 Posts
                    @BobRay:

                    Thanks! I've been following your tutorial and combining its methods with PackMan. I've also reviewed quite a few packages to see how Settings, Resolvers, etc work. I think the combining the two would be the best of both worlds. This should not be hard...

                    Are you planning on utilizing some of the UI features of PackMan?

                    Note: Sorry to nitpick, but you forgot a step. Insert at 1. Have a beer.

                    It has to be noted that my goal is to reduce development time, always. Often this means I spend time making the tools, so that I can reduce steps later on. Any situation that requires a fair amount of navigating or find/replace, I really find undesirable. I know that many others find this undesirable as well. This is why I work so much with Plugins/Snippets (it is also why I am now exploring building packages for others). In my experience, any process can be automated, and many should be. [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]
                      Website: Extended Dialog Development Blog: on Extended Dialog
                      Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
                      Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

                      Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
                      • 3749
                      • 24,544 Posts
                      If hope you mean my tutorial above, not the old MyComponent tutorial at Bob's Guides, which is not relevant to the new version.

                      TBH, I don't see any role at all for PackMan in the process. PackMan's only goal is to create a transport.zip file for you from objects that are in MODX. That .zip file won't contain System Settings. MyComponent's build.transport.php (created automatically by bootstrap.php) will create that same transport file *with* System Settings (once you export them) and will leave you with build files that you can edit when you want to improve the package, and a package you can manage with Git and push to GitHub.

                      A GUI to select the project to work on, create and edit the project config file, and run the utilities would be a logical next step, but I want to get everything in the package working first and have it pass all the unit tests. Editing the project config file by hand is tedious, but you only have to do it once for each project if you've planned it well.


                      The old MyComponent did require a lot of multi-file search and replace operations. The new version requires none.



                      ------------------------------------------------------------------------------------------
                      PLEASE, PLEASE specify the version of MODX you are using.
                      MODX info for everyone: http://bobsguides.com/modx.html



                        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