srakaislam.blogg.se

1. #Modx gitify which files should be version controlled update#
2. #Modx gitify which files should be version controlled code#
3. #Modx gitify which files should be version controlled series#
4. #Modx gitify which files should be version controlled free#

Assigning priorities to events isn’t supported.This is the drawback of registration-at-runtime vs registration-at-configuration. All plugins are loaded on every request, not just when they need to be executed.

#Modx gitify which files should be version controlled code#

Every time the OnWebPagePrerender MODX event is invoked, this code will run. Leaving aside the issue of loading, a plugin can now look something like: MODX Community: I need your ideas and input. Current approaches I’m playing with are hacky and nasty. MODX needs to know about the new plugin in a file I’ve created on disk, in order to load it and execute it. Meeting goal 2 comes as a free-win from modifying the event system the element cache is bypassed.Īs a bonus, because we’re executing the file we wrote and not the copy in the element cache, _DIR_ and _FILE_ are what you expect when you developed your code, and don’t point to the cache directory. Make some edits to the cached file to test, and you’d better remember to copy them to the real file soon - or you’ll clear the cache/MODX will detect your static element is updated, and over write your changes. Why does this matter? When you want to set a breakpoint and step through your code to debug it, you have to do so in the duplicate, cached version. This makes perfect sense when the code is in the database or residing on Amazon S3 (you need a local copy for PHP to execute), less so when it’s already local source code. Amazon S3), MODX creates two cached copies in core/cache. To meet goal 2, the major change is to make MODX use the file I’ve created, not its own copy of this file.Ĭurrently, whether the source code for my element lives in the database, a static file or on a media source (e.g. In other words, MODX needs an event system which code can register itself to. To meet goal 1, we need a way to register, and listen to, events without checking boxes. What’s needed to meet our goals? An event system so code can listen to MODX system eventsĬurrently, to make your plugin listen to a MODX system event, you have to check boxes in the MODX manager to tell MODX when this plugin should run.Ĭhoosing the events a plugin will listen to When it fires an event, it loops over the plugins registered to this event and runs each one. MODX builds a register of the plugins listed in its database, matched against the events they listen to.

MODX has done breaking changes before so have other projects. Keep backwards-compatibility with existing MODX installs People with existing websites expect them to keep working.Enable easier debugging Where to set breakpoints needs to be clearer and more straightforward than the current setup.In practice this means not creating the entry in the MODX database, and telling MODX about the element via code

#Modx gitify which files should be version controlled update#

Everything can be configured and managed from the filesystem If I update an element (a chunk, snippet, plugin or template) and push the changes to my webserver, it should be automatically picked up*.When looking at a better Git workflow, my goals are: The process works, but can we make the DX easier? To make the DX better, we need to… When the file on-disk is updated we have to remember to re-run Gitify. Use Gitify to dump the changes to the database to our hard drive, and commit it, along with our new file, to Git.Create the snippet by hand in the MODX admin area, setting the file we just created as a static element.Write a new element (let’s say a snippet) in PhpStorm, our favourite IDE.Our current workflow uses Gitify, and goes something like this: This has many benefits, not least a continuous history of changes to the project. When developing a new MODX project, as developers we keep our code in Git source control. The MODX CMS excels at content management, with our clients finding the admin interface easy to use, far more so than their previous Content Management Systems (CMS).īut the developer experience of building and maintaining a MODX site hasn’t lived up to the admin area’s high standards.

#Modx gitify which files should be version controlled free#

The atmosphere is toxic and I choose to spend my free time in healthier places. Important! As of June my involvement with MODX development is on-hold until the team sorts out some issues around politeness and respect.

#Modx gitify which files should be version controlled series#

This is the first post in a series about enhancing the Developer Experience (DX) when building sites and applications on MODX. Improving the MODX DX: A better Git workflow