MODX

A new feature release of MODX Revolution is coming soon and we've published the second release candidate for MODX Revolution 2.5, today. What's New in Revolution 2.5 This new release of MODX Revolution includes a number of excellent new features ... [More] including: PHP7 compatibility (it's coming soon to a server near you) Much more mobile-friendly Manager as a stepping stone towards a new manager in the future. Custom Manager Pages (the views for applications built into MODX) are now much easier to build using HTML and MODX Tags. Thanks to Romain Tripault and Susan Ottwell for this example of the new Custom Manager Pages in 2.5. Accessibility improvements worked into the core Manager experience including screen reader and keyboard navigation on the Login screen. Significant improvement to the parser which could potentially improve pre-caching performance by 15%; New installs get a new look. Instead of the empty blank page in previous versions you now get a nice intro page with some important links so new users can more easily get started. Contributors on this Release Let’s take the time to thank the individual contributors to this release (in no particular order):Jan Peca, Jason Coward, Thomas Jakobi, Ronald Exterkate, Mike Reid, inreti, Zaigham Rana, Jan Tezner, Elizabeth, Romain, argnist, Anton Pastukhoff, Илья Уткин, Gildas NOEL, Ivan Klimchuk, JP DeVries, Kirill, Mark Hamstra, Mat Dave Jones, Nikolay Lanets, Sergey Shlokov, and Vasily Naumkin, along with many other contributors who log & triage issues, review PRs, and commit code. The MODX Community is Amazing. Ready, Set, Test Revo 2.5 In order for a successful release of 2.5 we need people to test these release candidates on their projects, of course, do keep in mind there will be bugs—that's what we're looking to find. Here’s what you need to get started or upgrade to MODX Revolution 2.5-RC2: Download Revolution 2.5 What’s required to run Revolution 2.5.x How to install MODX Revolution How to upgrade MODX Revolution on your site Read the MODX Revolution Documentation It Takes a Global Village MODX is only as good as it is because of the many individual community members and users, from around the world, who take the time to report issues, request new features, and submit code to the project. Make sure you read the documentation,post feedback and share your experiences in the MODX community forums. On behalf of the entire MODX Team, We thank you! [Less]

Another patch release of MODX Revolution 2.4, 2.4.4 is now available. The key fix is a regression bug that caused problems with output filters (modifiers). If you missed the 2.4.0 announcement, check out the details here. Highlights from the ... [More] changelog: Make sure only recipient can mark user messages read/unread [#12944"> Do not attempt to clean cache_db_handler if cache_db not enabled [#12942"> Fix broken output filters on undefined placeholders introduced in this commit. Important: The 2.4 releases contain vital security patches from 2.3.6. If you are using a version lower than 2.3.6 you should consider an upgrade to 2.4.4 mandatory. Security is an Ongoing Process We cannot stress how important it is to run the most current version of MODX. We are always improving security. Upgrade regularly to reduce the chance of your site getting hacked. If you need help upgrading your MODX site, let us know. Get Started with Revo 2.4 Here’s what you need to get started or upgrade to MODX Revolution 2.4: Download Revolution 2.4 What’s required to run Revolution 2.4.x How to install MODX Revolution How to upgrade MODX Revolution on your site How to upgrade MODX Revolution in MODX Cloud Read the MODX Revolution Documentation Ask Not What MODX Can Do For You MODX is only as good as it is because of the many individual community members and users that take the time to report issues, request new features, and submit code to the project. Make sure you read the documentation,post feedback and share your experiences in the MODX community forums. On behalf of the entire MODX Team, We thank you! [Less]

It's February 29th and it only comes around once every 4 years, which makes it a little special. Speaking of things that don't happen often, it's been 15 months since the last release of MODX Evolution. The international community-led team that is ... [More] behind the current release, have made some important changes since that time including replacing the frameset in the Evo Manager with iFrames, virtually eliminated the document Resource limitations, and the team has worked very hard to make Evo fully compatible with PHP 5.6 through to, and including, PHP 7. Due to the time since the previous release and the significant number of changes for both security and PHP server compatibility, Evolution 1.1 should be considered mandatory update/upgrade for all users of MODX Evo 1.0.15 and below. uick stats on the multitude of changes that increase the capabilities of Evo for the release of MODX Evolution 1.1: Bugfixes: 44 Refactor: 35 Additional Improvements & Updates: 35 Commits: 322 Files changed: 293 Participants: 21 Important changes to note: Deprecated Mysql replaced with Mysqli, to ensure compatibility with PHP 5.6 + Manager no-longer uses a frameset, it now uses iFrames New manager setting "AliasListingFolder" - Setting => Friendly URLs (tested with 1000000 documents, no more limits for documents) DocLister is now a default snippet - English documentation can be found in the RTFM, courtesy of "kp52" who translated the official Russian documentation Read the changelog for complete details on changes in 1.1 We would like to thank the dedicated community-based MODX Evolution team behind these changes: Dmytro Lukianenko (Dmi3yy) D.Helfensteller (Deesen) Agel_Nash (AgelxNash) Sergey Davydov (MrSwed) Kari Söderholm (Haprog) YAMA (yama) Thomas Jakobi (Jako) and: Zevseg, Segr, TimGS, jasonabird, bossloper, Eoler, fourroses666, rpre, pmfx, kulmjens, MaXL-ru, janniconl, Fess7, esszett And thanks go out to all those users who took the time to test and who contributed bug reports. Download Evo 1.1: You can download the latest version of MODX Evo from the following sources: The official MODX website Evo download page MODX Evo GitHub repository Useful Evo Links: For those users who are interested in using Evo, but are unsure where to begin: Basic Installation - How to install Developer's Guide - All tech infos (How to, What are etc.) Content Editing - For editors, user creation etc. Administration - How to manage users, moving site etc. Designing - Templates, adding chunks, TV's, snippets etc. Haven't updated / upgraded Evo in a while, no worries, check out the guide here [Less]

Another patch release of MODX Revolution 2.4, 2.4.3 is now available. If you missed the 2.4.0 announcement, check out the details here. Highlights from the changelog: Prevent uncacheable elements from being cached in cacheable elements ... [More] Fix loading rich text editors on non-document resource types Cache-busting token added to manager js and css links to force refresh after upgrades Corrected dashboard's save button action Fix modX->getUser to force load settings when parameter is passed Various config_check improvements …and a variety of other improvements & bug fixes Important: 2.3.6 contains a security patch and is considered a mandatory update. 2.4.0 contains all patches from 2.3.6, and also closes the security issue. 2.4.3 is a non-critical patch of the 2.4 branch. Contributors on this Release Let’s take the time to thank the individual contributors to this release (in no particular order):Mark-H, pixelchutes, Alroniks, hansek, inreti, oori, jpdevries,whitebyte, Jako, tehsquidge, rtripault, ViieeS, yoleg, tyllo, theboxer, along with many other contributors who log & triage issues, review PRs, and commit code. The MODX Community is Amazing. Security is an Ongoing Process We cannot stress how important it is to run the most current version of MODX. We are always improving security. Upgrade regularly to reduce the chance of your site getting hacked. If you need help upgrading your MODX site, let us know. Get Started with Revo 2.4 Here’s what you need to get started or upgrade to MODX Revolution 2.4: Download Revolution 2.4 What’s required to run Revolution 2.4.x How to install MODX Revolution How to upgrade MODX Revolution Read the MODX Revolution Documentation Ask Not What MODX Can Do For You MODX is only as good as it is because of the many individual community members and users that take the time to report issues, request new features, and submit code to the project. Make sure you read the documentation,post feedback and share your experiences in the MODX community forums. On behalf of the entire MODX Team, We thank you! [Less]

Photo: Five Days’ Backup, by daryl_mitchell Backups of your websites are critical—you will eventually need them. Even today too many hosts still don’t backup by default, or they only grab the files and leave your database out of the picture. ... [More] Likewise, many hosts’ backups are difficult or slow to access, requiring help from support. If something goes wrong, it can be costly and stressful. Or worse… MODX Cloud launched years ago with automatic, offsite backups stored on redundant disks, on a rolling 7-day basis. You can also create manual backups any time that are only culled when you manually delete them. Anyone with Dashboard access can restore from backups without needing to open a support ticket. It’s the way backups should be. But we had requests for more control over the schedules so MODX Cloud users can keep within their plan storage limits. Today we’re happy to announce you can adjust the backup retention schedule for each Cloud instance. Set them to as low as a single nightly backup, or increase them to up to 30-days of retention on a rolling basis. We won’t let you disable backups completely. ;) Adjusting the backup schedule is simple. Click on the name of the Cloud from the Clouds view, click the Backups tab, and move the slider. Saving is automatic and the schedule will be adjusted for the next round of backups later that night. To learn more in the Backups in MODX Cloud section of the User Guide. We hope you enjoy this requested enhancement in MODX Cloud. [Less]

Photo: Five Days’ Backup, by daryl_mitchell Backups of your websites are critical—you will eventually need them. Even today too many hosts still don’t backup by default, or they only grab the files and leave your database out of the picture. ... [More] Likewise, many hosts’ backups are difficult or slow to access, requiring help from support. If something goes wrong, it can be costly and stressful. Or worse… MODX Cloud launched years ago with automatic, offsite backups stored on redundant disks, on a rolling 7-day basis. You can also create manual backups any time that are only culled when you manually delete them. Anyone with Dashboard access can restore from backups without needing to open a support ticket. It’s the way backups should be. But we had requests for more control over the schedules so MODX Cloud users can keep within their plan storage limits. Today we’re happy to announce you can adjust the backup retention schedule for each Cloud instance. Set them to as low as a single nightly backup, or increase them to up to 30-days of retention on a rolling basis. We won’t let you disable backups completely. ;) Adjusting the backup schedule is simple. Click on the name of the Cloud from the Clouds view, click the Backups tab, and move the slider. Saving is automatic and the schedule will be adjusted for the next round of backups later that night. To learn more in the Backups in MODX Cloud section of the User Guide. We hope you enjoy this requested enhancement in MODX Cloud. [Less]

We continue making improvements to MODX Cloud to make it a more flexible platform, and to bring things that used to require complex technical chops to everyone. Most notably, we added support for Node.js in MODX Cloud. This means front-end ... [More] developers can use it for workflow tools like Bower, Grunt and Gulp, amongst others. If you’d like to try it out, request it for your specific Cloud instance by using the help link in your MODX Cloud Dashboard. We also want to remind you about the recently added Flex Cloud instances which give you access to the filesystem above webroot. You can use them to install other software like MODX Evolution or another CMS, or even frameworks like Slim, CakePHP and Laravel. Flex Clouds include a highly tuned nginx web server and an empty MySQL database instance. Automatic offsite backups occur every night, and we store them for 7 days on a rolling basis. A few other noteworthy updates include: Fixed a minor sorting bug to list the accounts you have access to in alphabetical order. MODX Cloud instances can now be upgraded to be fully managed, monitored and maintained for customers on current plans from the Cloud management view. Formal announcement coming soon. ;) Fixed additional UI bugs, adjusted the UI in spots, and updated documentation to improve the overall experience in MODX Cloud. Many, many underlying platform updates to set the foundation for new functionality and products starting in early 2016. What’s Next Go check out the MODX Cloud Roadmap, and you tell us what you’d like to see! We look forward to your thoughts. [Less]

We continue making improvements to MODX Cloud to make it a more flexible platform, and to bring things that used to require complex technical chops to everyone. Most notably, we added support for Node.js in MODX Cloud. This means front-end ... [More] developers can use it for workflow tools like Bower, Grunt and Gulp, amongst others. If you’d like to try it out, request it for your specific Cloud instance by using the help link in your MODX Cloud Dashboard. We also want to remind you about the recently added Flex Cloud instances which give you access to the filesystem above webroot. You can use them to install other software like MODX Evolution or another CMS, or even frameworks like Slim, CakePHP and Laravel. Flex Clouds include a highly tuned nginx web server and an empty MySQL database instance. Automatic offsite backups occur every night, and we store them for 7 days on a rolling basis. A few other noteworthy updates include: Fixed a minor sorting bug to list the accounts you have access to in alphabetical order. MODX Cloud instances can now be upgraded to be fully managed, monitored and maintained for customers on current plans from the Cloud management view. Formal announcement coming soon. ;) Fixed additional UI bugs, adjusted the UI in spots, and updated documentation to improve the overall experience in MODX Cloud. Many, many underlying platform updates to set the foundation for new functionality and products starting in early 2016. What’s Next Go check out the MODX Cloud Roadmap, and you tell us what you’d like to see! We look forward to your thoughts. [Less]

ICYMI (In Case You Missed It) Recently—with the support of the MODX Core Team—I released two MODX Extras: OAuth2Server and Zapier. The use cases, features, roadmap and documentation for these Extras are in their respective Github repos: ... [More] OAuth2Server on Github Zapier on Github The process of making these Extras was, for me, a crash course in several areas of MODX development, in which I had limited experience and understanding. No one person can know everything about MODX (as even Jason Coward, Chief Architect, will attest). While I'm confident doing many varied things with MODX—to scale—making a CMP is not one of them. This multi-post series is an attempt to document my learning, both for my own future reference and for anyone else who wishes to learn. Choose Your Weapons Without these tools, development may have been impossible, slower, or at least less enjoyable: Git Package Management Github oauth2-server-php MODX Cloud Sequel Pro Postman Google, and Google Chrome Dev Tools And, of course MODX and xPDO, as well as my code editor, Coda (although I think a more robust and appropriate IDE like phpStorm would be beneficial). Project Goals/Requirements The primary goal of this whole exercise was to allow us, at MODX, to integrate our contact forms with our tools of choice for CRM, support, analytics, communication, and project management. I could've developed integrations for each and every tool we use, but our Chief Shiny Objectifier Ryan Thrash has always expounded the virtues of Zapier, leading me to daydream—for the better part of two years—about the day that MODX could connect with it. That day hadn't come, so true to Internet culture, I chose to attempt it myself. OAuth2 and Zapier These are pretty big topics—here's a 50,000ft overview. Your MODX site needs a way to "know", for certain, that a Zapier account (or any other requester) has the permission to access whatever resource it is requesting. It's the equivalent of you logging into your MODX Manager, except it's some machine in The Cloud doing it. So MODX needs a way to separate "good" machines (that have permission) from "bad" machines (bots, hackers, and whomever else happens across your resource URLs). Zapier needs to know that you have the permission to grant Zapier permission to your MODX site (Inception, slightly). Zapier supports multiple ways to do this, but for more reasons than I can list here, OAuth2 has become the "gold standard"—specifically, "3-legged oauth with Authorization Code". NOTE: for simplicity and brevity, for the rest of this post, "MODX" will refer to your MODX site, to which you want to connect Zapier, and "Zapier" will refer to your Zapier account. Eye-Opener 1: The Ins and Outs of OAuth2 The way it works is: In MODX, you create a Client ID and Client Secret (think username and password) with which to identify Zapier. Remember this means your Zapier account. You can connect multiple Zapier accounts using multiple Client IDs, but that's not what we're talking about here. In Zapier, you add a connection to MODX and provide the Client ID and Client Secret so it can "be" that "user". Zapier is "Leg 1", the Consumer. Zapier forwards you to an "Authorization URL" at MODX. You must be logged into MODX, and your MODX User must have the permission to authorize access. You are "Leg 2", the owner of the resources in MODX. When you grant permission, MODX sends Zapier an "Authorization Code" which expires in a short time. MODX is "Leg 3", the API or Provider. Zapier makes a request to MODX, with the Authorization Code, Client ID, and Client Secret, and if all are valid, MODX grants an "Access Token" in the response. All future requests made by Zapier to MODX will include this Access Token, which will be the sole identifier of Zapier, at the level of access you granted it. With this, you have fine-grained control over the access to your site. If you remove an Access Token, none of Zapier's requests will be allowed. If you delete or modify the Client ID or Client Secret, Zapier will need to be authorized again, by you, in order to gain a new Access Token. MODX "knows" it's your Zapier account because of the combination of Client ID, Client Secret, and your manual authorization. Zapier "knows" you own the site because you were able to make MODX send an Authorization Code, and it "knows" you allow it continued access as long as MODX accepts the provided Client ID and Secret as valid. It seems daunting at first, but distilled to its core principles, it makes a lot of sense. The downside was that MODX didn't support this... Turning MODX Into an OAuth2 Server At the bare minimum, 4 things need to persist in MODX for this to work: Client ID Client Secret Authorization Code Access Token I often make crappy, un-optimized versions of things on the first go-round. My prototype stored Client credentials in MODX System Settings, and the latter two in User Settings. This worked, but you could only have one set of Client credentials, the Authorization Code didn't expire, and Access Tokens couldn't be refreshed automatically, but the idea was valid. Jason, being prudent and careful in all things, suggested I use a well-established library for the next iteration: oauth2-server-php Following the cookbook, I manually executed the SQL statements to create the database tables, and included the necessary classes from the library in my Snippets. It worked, with only a reasonable amount of fussing about. The Postman Chrome extension was invaluable for testing the POST requests. Eye-Opener 2: PHP Object Interfaces Interfaces are like run-of-the-mill PHP classes in that they can be extended, and they have member functions, also called "methods". However, interface methods don't do anything. Their internals are defined in the class that "implements" the interface. The interface defines "what" functionality is required, but is completely agnostic to "how" it's accomplished. From the PHP docs: The class implementing the interface must use the exact same method signatures as are defined in the interface. Not doing so will result in a fatal error. It's basically a list of (strictly) required functions. The author of the oauth2-server-php library needed a way to support various storage options, but maintain full control over the functionality that any storage option would provide. The interface design pattern perfectly suits this use case. At this point I was toying with the idea of writing a class using xPDO methods to implement the library's storage interface. Jason advised me against this—turns out it wasn't needed, but I'm considering it for a future release, just to satisfy my own interest. Understanding this design pattern was very helpful, for wielding the library effectively. It features a PDO storage class, which plays nicely with MODX. (You just have to pass in an array of table names, which the OAuth2Server "wrapper class" in the Extra will do for you.) With that working, the next step was to build a package that could be installed via the MODX Extras Installer. This would require another first for me. Next up in this series: Part 2: Writing xPDO Schema [Less]

This is Part 2 of a 3-part series. If you haven't read Part 1, I'd suggest starting there for background info that's relevant to this post. Eye-Opener 3: Writing xPDO Schema Designing an optimized and performant data model, and structuring ... [More] properly indexed tables, is a craft unto itself. For this project, I relied on the work of the maintainers of the oauth2-server-php library. It was enough of a learning curve to recreate their data model using xPDO's XML schema syntax, without also trying to learn the intricacies of database optimization—especially because I have no reason (yet) to believe that their data model needs optimizing. xPDO has methods to generate the class files necessary for your app, in this case MODX, to interact with the database objects. I'm not too familiar with those methods, but John Peca's utility Git Package Management executes them, based on the XML schema you provide. So, at the heart of this phase of the project, was this XML doc—and actually xPDO makes it fairly straightforward to create these. Essentially there's three levels of nodes: defines the package, to which all child object nodes belong, and according to the xPDO docs: The "model" tag is a representation of the database itself. defines a database table, and thus, via xPDO, a PHP class of object. defines a column in the table, which is defined by the parent object. NOTE: I had the benefit of referencing an existing XML schema document written by John "TheBoxer" for a package with a similar model. I'll try to elucidate "why" things are done the way they are, but admittedly I'm no every little detail. Writing the model node was a copy/paste operation, except for the "package" attributes. You can omit the "tablePrefix" and xPDO will use the prefix defined in your MODX config. The one attribute that caused some grief was the "version". The documentation shows examples of using an index node as child of the field node, which requires the "version" attribute of the model to be "1.1". However, when I tried that, Git Package Management would not create the tables. Using a previous version, the index is defined with an "index" attribute on the field nodes. This worked, so I used that. Curiously, in John's example, he specifies version "0.1" which isn't documented, but worked. That's what I used but I'll have to ask him for details about it. For now, let's move on. The object node has three attributes: class table extends The first 2 are fairly self-explanatory and well-documented. The third specifies an object class to extend. The examples in the docs, and John's example, use "xPDOSimpleObject" but the oauth2-server-php library requires specific primary keys for each of its tables, so the auto-incrementing ID that comes with "xPDOSimpleObject" wouldn't work. (I tried.) For those tables I used "xPDOObject", which worked nicely. The field nodes support quite a few options, which are well-documented, but I'll highlight a few gotchas here: If you omit the "null" and "default" attributes, then the field can be NULL and the default value will be NULL. Your application logic may require this, or it may choke on it. Be sure to know what's needed, or test against it. xPDO offers validation methods, but I haven't dived into these yet. I speculate they'll be very useful. If the model uses "version" < 1.1, add index="pk" to the field you want to be indexed as the primary key. For timestamp fields, here are some example attributes that work: dbtype="timestamp" phptype="timestamp" default="CURRENT_TIMESTAMP" attributes="ON UPDATE CURRENT_TIMESTAMP" I couldn't find an example of a boolean type, so I used: dbtype="tinyint" precision="1" attributes="unsigned" phptype="integer" In the Git Package Management UI, there's a context-menu item "Create classes with schema". Selecting it will generate the xPDO class files. To use the classes in your code, you call the $modx->addPackage method, documented here. I call it in my class constructor, but that's not necessarily always the best place—I just found it convenient. NOTE: some pages in the documentation advise not to specify the 3rd argument to addPackage(), for table_prefix, but I found my classes wouldn't load without it. One of the gotchas I ran into was that instantiating my class from inside a custom FormIt hook, I inadvertently overrode my class's default config with FormIt's config. Take-away: do NOT pass the $scriptProperties array to your constructor, via getService() or any other method, when writing a FormIt hook. In a standalone Snippet, it exposes options to be configured at run-time, which can be handy, but in a FormIt hook, it has all of FormIt's properties, which wreak havoc with those of the class you're instantiating. Another gotcha, in my particular use case, was ensuring my model was fully compatible with the oauth2-server-php library. I had Sequel Pro on one monitor, and referenced the table structure as I wrote the XML, in Coda, on the other monitor. The library seems to be pretty specific about its needs, failing until my xPDO-created tables were identical to the ones created by the SQL statements in their documentation (with the exception of the boolean field type). If you're developing a custom component from scratch, you probably won't have this issue. Take-away: don't try to skimp on the model. While slightly tedious, this whole schema-writing affair has great benefits, both for learning and subsequent convenience. Now, after adding my class, I can access my Extra's tables as easily as any MODX object: $modx->getObject('OAuth2ServerClients', array('client_id' => 'exampleClientId')); SO awesome. And yes, I named my object class in the plural form. That's probably gonna have to change, otherwise it'll drive me nuts. Now that I could interact with my objects programmatically, the next step was to expose CRUD functionality to the end user. In MODX, this means a CMP, which means ExtJS, another weak point for me. Next up in this series: Part 3—ExtJS Grid and Custom Manager Pages Other posts in this series: Part 1: MODX+OAuth2+Zapier—How to Make an Extra with CMP [Less]