MODX

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]

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 3 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 4: ExtJS Grid and CMP Despite the fact that John Peca was away on a remote island while I was ... [More] doing all this, it really cannot be overstated how much I relied on his "input". Again, I scrutinized the work he did on a component with similar features, and thus learned the lion's share of what I needed. Upon his return, I got on a call with him and picked his brain. Here's the culmination of what I've learnt so far about ExtJS and CMPs. For brevity, in the following description when I refer to "core path" and "assets path", I mean the "namespaced path for the Extra", usually: {$core_path} or {$assets_path} and then components/{$namespace}/. Also, I'll refer to the filenames from the OAuth2Server Extra, as examples, so it might be helpful to have the files from the repo open while you follow along. GPM adds the menu action to the package it generates, so when you install your Extra, there'll be a menu item under "Extras". Revo > 2.3.x automatically loads an action class from the controllers directory of the core path, with the filename {$action}.class.php. In this case: {$core_path}components/oauth2server/controllers/manage.class.php. The "manage" class includes the "index" class from the parent directory. Still not sure why both these classes couldn't be in one file, even though I asked John about this—I didn't understand the answer or maybe wasn't listening closely enough LOL. It might be preference, or for code organization, because the class in the "manage" file extends that in the "index" file. Anyways these two classes have methods that register the CSS and JS required for your CMP. The "index" file also has a method that loads lexicon topics into the ExtJS config. More on lexicon usage later. The assets folder has a file connector.php. This instantiates MODX itself, along with the OAuth2Server class, and acts as a "gateway" to the processors, usually found under the core folder. In other words: {$assets_url}components/oauth2server/connector.php -> hands requests to -> {$core_path}components/oauth2server/processors/{$action} The processors do things like: get lists of objects, validate the inputs, create objects from that input, etc. But where do all these inputs come from? Here's where the ExtJS "magic" (or "devilry", depending on your viewpoint) happens. In the assets folder, there are subfolders for CSS and JS. CSS makes stuff look nice. Under the js/mgr/ folder there's a JS file, in my example oauth2server.js. In that file, we "extend" the Ext.Component "class" and "register" it, so ExtJS "knows" about it. (For convenience I'll use the keywords introduced in ECMA 6, but when ExtJS 3.4 and Revo were first developed, "class" wasn't really a "thing" in JS.) In a subfolder sections/ there's a file manage.js, which extends MODx.Component and registers it. In the subfolder widgets is where the fun begins. The manage.panel.js file extends the MODx.Panel class and registers it. But it also configures the panel with tabs, one for each custom-registered "xtype". That brings us to... The actual widgets; for example, clients.grid.js extends MODx.grid.Grid and registers it. Note the first argument to Ext.reg() is the xtype value used in manage.panel.js—see how that connects? A registered component can be configured as part of another component by referencing its "xtype". I'm not pretending to understand fully how this works but a lightbulb went off in my head when I saw this so I thought I'd point it out :P There's a LOT going on inside clients.grid.js so let's start a new list. That'll make this insanely large post more readable, right? Near the top, there's a function Ext.applyIf(), which basically sets config options. Wherever you see an action property in the options, it's setting a target class file, within the Extra's processors/ folder that we talked about earlier, to which to send requests, via the connector. (It can't send requests directly to class files in the core folder because the core folder is not supposed to be web-accessible.) There's a bunch of options to configure the grid columns. I won't go into an exhaustive review of those right now, but here are some docs on ExtJS grids. There's a tbar property that adds buttons to the top of your grid. Note alot of the properties that define UI text strings or labels refer to MODX lexicon entries, like this: _('oauth2server.clients.add'). Those are defined in {$core_path}components/{$namespace}/lexicon/{$cultureKey}/{$topic}.inc.php and loaded by the "index" class file we talked about earlier. The Ext.extend() function defines our custom methods: getMenu() adds a context (right-click) menu. addClient() is the method called by the button defined in the config. It loads another component, which extends MODx.Window, defined in the file clients.window.js. It's the modal window with the form elements to create and update individual row items. updateClient() is similar to addClient() but it passes in a custom variable—we'll go over that when we review the clients.window.js file. duplicateClient() calls the create action but prefills the field values. removeClient() calls the processor that deletes a row item, with a call to MODx.msg.confirm(), to show a confirmation window. Now we have a grid, with a button and context-menu items that do things. The last piece of the puzzle is the clients.window.js. The bulk of this file is a call to Ext.applyIf() so basically we're configuring this modal window. By now you may recognize some of the properties, like action for example. The fields property defines an array of form fields, each having some options to play with. xtype is the only one that isn't self-explanatory, because there are lots of MODX-specific xtypes as well as those added by Extras. I don't even think they're all documented in any one place, except Bob Ray has a list. The only other interesting bit is the custom variable passed through to set the client_id field to readonly:true. John clued me in to the fact that custom variables can be used, and that readonly was was the property to use. Previously I'd tried disabled: true but in that case the client_id field value got stripped from the request to the processor. Take-away: don't use disabled. Wow. Ok, so that pretty much sums up my adventures in CMP-land. Did I wake up afterwards, only to realize it was all a crazy dream? Haha. No. But I did have this tiny glass bottle in my pocket with a label that said "MODX Me" :P Other posts in this series: Part 1: MODX+OAuth2+Zapier—How to Make an Extra with CMP Part 2: Writing xPDO Schema [Less]

Avoiding a Content Management Disaster Chances are you’ve been there: you quickly make what should be a simple change to a site but you wind up with a mess. You save over the wrong page on accident, break the formatting of your site, or worse, tweak ... [More] something that winds up taking your site offline. The vast majority of users work on live sites, and most of the times it just works. Except when it doesn’t. At best, it’s frustrating and you have to scramble to fix things. Often it can have real monetary or reputation implications. Some site owners come up with creative ways to keep work in progress out of the public eye, like duplicating pages to start work on new content. There are Extras that allow you to make drafted changes prior to publishing, and others to roll back to changes when things go wrong. These are fine for individual pages, and we use them ourselves. We even used Complete Snapshots in Cloud (see below), but it was not ideal. When you’re working on many pages for a campaign, or creating a new section for your site, things can get complex and require careful coordination. The time tested, recommended practice for managing updates to an important website is to use a Staging site. But let’s be honest: in the real world, it’s hard to do things right, especially when you don’t have a technically savvy dev team and sysadmins backing you up around the clock. Introducing the Promote Snapshot The new Promote Snapshot in MODX Cloud allows you to capture the right content, Elements and new system settings, leaving users, and existing system settings alone. This is seriously cool, and lets even completely non-technical teams manage their sites the right way, without having to think about it. It’s even smart enough to push new settings over, and to leave existing ones alone. A Real World Example: modxcloud.com The MODX Cloud marketing site constantly changes, especially the User Guide. While it is a fairly simple website with a small signup application, we make, preview and test changes in a staging environment and then deploy completed and approved changes to the live site. Doing this one page at a time on the live site simply won’t work. More importantly, we have different settings on the staging and live sites, so we can test without worrying about dirtying up the data in production. These things include: Analytics Account IDs A test Billing System URL A test Checkout URL Test Users Test CDN zones Before Promote, we had to go through a cumbersome process. Granted, MODX Cloud Snapshots probably cut the migration time in half, but we knew it could be a lot better. Here are the steps we had to go through to move from the staging server to the live site: Snapshot the Staging site everyone approved using the Complete Snapshot template. This is a safety net to fall back on if needed, and is in fact needed in the last step of this process. It’s also nice to keep for historical archives. Find the checklist containing all the caveats and gotchas to look out for. Don’t ask how we came up with the list. Meticulously change the settings in Staging to match the live site by copy/pasting. Snapshot the Staging site with the updated settings using the Complete Snapshot Template. Snapshot the Users from the live site using the Users Snapshot template. Back up the live site using the Cloud Dashboard. When the backup is complete, inject the Staging site Snapshot from step 4 into the live site. Hope this goes quickly! Inject the users from the live site take in step 5 into the newly injected live site. Test the live site. Inject the Snapshot from step 1 back to Staging site to reset it and its test data. After doing this for months, on a good day we managed to get this process down to about 15 minutes, depending on how recently we had last done a push from stage > production. It was not uncommon for this to take 30+ minutes. If you had never done this before it was intimidating, but way better than doing it manually from the command line. Now with the Promote Snapshot After the Cloud team created the new Promote Snapshot, here are the steps it takes to move our changes to the live site: Snapshot the Staging site with the Promote Snapshot Template. Backup the live site (in extremely rare case of an issue—none have happened so far). Inject the Snapshot from Step 1 into the live site. There is no step 4 … it’s done! This process is way faster, taking about 3-4 minutes from start to finish. Since it’s so easy, it makes it so you’re willing to make changes more frequently, and more people can update the site, too, because it’s virtually foolproof. Using the Promote Snapshot If you have a website where you should review content or design changes before pushing those updates into production, Promote Snapshots are for you, today. This is especially true when multiple people in an organization have a say in what happens on your website. Standard Promote Snapshots are available to any customer on a current Basic, Pro, Studio or Agency plan. Customers on legacy plans will need to choose one of the new plans to use Promote Snapshots (there’s also much more coming for the new plans). If your site has custom data, such as comments or user generated content, the Promote template will copy it all from your staging site and replace it on your production site. This may or may not be the behavior you want, depending on the use case. Customers on Agency or Premium plans can request a custom Promote Snapshot template to fit your site perfectly, as we did for modxcloud.com. Set Up Your Own Staging Environment To get started with your own Staging environment, follow the simple steps below: Take a Snapshot of your live site using the Complete template. Create a new Cloud from this Snapshot. Customize settings and users that should differ between Staging and Production. Finally, It’s Easy to Stage Your Site Correctly We hope you’ll find the new Promote Snapshot helps you manage your content in a much more effective manner. Let us know what you think. [Less]

We recently launched Flex Clouds, which makes MODX Cloud a great place to work on pretty much any site. We've now added to the documentation, starting with how to install MODX Evolution and WordPress. Flex Clouds are perfect for when you need a ... [More] place to put a project you’re planning to migrate to Revo, for installing utility apps like Piwik analytics, exploring e-commerce, or for when your client forces you to use a clearly inferior alternative CMS. ;) Flex Cloud instances give you access to all the Cloud Tools that work for MODX Revolution, including access to the filesystem above webroot for installing frameworks like Slim and Laravel, a highly tuned nginx web server, and an empty database instance. Automatic offsite backups occur every night, and we store them for 7 days on a rolling basis. You can even install MODX Revolution manually in a Flex Cloud, but you will not have access to Snapshots and workflow tools unique to MODX Revolution. There’s Always More… Other noteworthy updates include: Sensitive credentials for database and SSH connections are now hidden from plain view. Thanks to JP DeVries for bringing this up—it makes demoing the system and training people much less delicate. Updated to the latest PHP 5.6.15 version. UI updates including a streamlined header and account switcher, and a link to the public roadmap in the Dashboard footer (you should go vote for things there!). Fixed a longstanding bug with the paging of lists for some users. Fixed a bug that resulted in incorrect size recording for Backups and Snapshots. Related, we confirmed the old limit of 4GB for both is long gone. Fixed bug in the implementation of cron task handling that caused them to intermittently fail. 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]

Many customers told us how much they love the speed, stability and performance of MODX Cloud for Revo, but they wanted other PHP apps without workarounds, too. Today, their wait is over. We’re excited to introduce Flex Clouds—a standalone Cloud ... [More] type that comes with an empty database, SSH and SFTP, ready for you to install virtually anything that runs on a modern nginx/MySQL/PHP stack. Automatic rolling 7-day offsite backups keep your Flex Cloud projects safe, so you can sleep well at night. For front-end developers, Flex Clouds support Sass and Compass Watch. For those that live in IDEs and Text Editors, you can use the command line for modern developer tools like Composer, Git, cron, shell scripts, rsync, Nano and Vim (sorry Emacs). Many customers have been holding on to legacy hosting accounts to run their MODX Evolution and WordPress sites; today we have removed the barrier to moving to MODX Cloud. You can now have all your legacy and current projects in a single place, and update them to MODX Revolution when the time is right. For customers on the original plans, we will shift your WordPress Clouds to the new Flex Cloud type; you won’t need to do anything. If you need a new WordPress Cloud, use the Flex Cloud type and install the latest version from the web installer or from a CLI tool of your choice. We’ll add instructions for installing WordPress and MODX Evolution, and other apps that you request. This is just the first of several other expanded capabilities coming to MODX Cloud this year. Keep an eye out for what’s next, and tell us what you’d like to see. [Less]

MODX Cloud is giving some overdue attention to accountants and bookkeepers. We hope to make our number-crunching friends’ jobs easier with a new billing system and plans that bring detailed consolidated invoices, lower prices, and increased storage. ... [More] In addition, we’ve re-introduced the Agency plan for customers that need more storage than was previously available as standard. Subscribers on the old billing platform can elect to migrate to the new plans today, but for those already there, your next invoice will be lower with at least double the storage space. It’s our way of saying “thanks”, and giving you more room to work ahead of the coming new features. In addition to ongoing UX and documentation improvements, other highlights from the last few weeks include: Kept up with the MODX Revolution releases by adding 2.4.1 and 2.4.2 as install targets, allowing site builders to stay at the forefront of MODX development. Updated to PHP 5.6.14 to keep up with the latest bug fixes and security updates, keeping developers more productive and site owners safer. Made updating your payment method simpler by making a link available in the sidebar on all account-related pages, and adding documentation with instructions on how to update your payment method. Users can pay via both Paypal and credit cards on the new billing platform, giving them more flexibility and convenience. General documentation improvements including better organization, creating content for every top-level section, and clarifying the SSL format for user-supplied SSL certificates. Don’t forget you can always test SSL for free on any internal MODX Cloud URL, so you don’t have to worry about overlooking things before launching and installing an SSL cert on a live production site. Added instructions on using Sass and Compass Watch in MODX Cloud. If you ever want to try out Sass, just open a support ticket from the MODX Cloud dashboard and we’ll be happy to hook you you up. Added documentation to access site logs for troubleshooting in MODX Cloud, so developers can be more productive in MODX Cloud. Fixed a longstanding issue with the chroots which prevented Imagemagik from being used for generating thumbnails of CMYK PDF documents. It is now possible but requires custom code since no current Extras including the suggested pThumb and Resizer use Imagemagik for this. As a result, MODX has adopted these two key Extras and will update them to use Imagemagik when available by default. What’s Next As mentioned previously, the new billing system allows us offer upgrades for both individual Cloud instances and your plan a whole. In addition, we can use it for one-time billing events, for instance if you wished to hire us to help speed up your site (we’re really good at optimizing MODX ;) ). In addition to users upgrading their storage, the first few instance upgrades include the following: Double the PHP workers for the front-end of sites in MODX Cloud for $10/month/site. This allows your projects to handle more intensive processor loads that otherwise might time out or take too long, resulting in timeout errors. Dedicated PHP worker pools for the MODX Manager allow you get into the Manager back end even if the front end is currently timing out. This allows you to troubleshoot your site without opening a ticket to get your site rebooted, for $10/month/site. SSL Certificates will move to instance upgrades, free for Studio and Agency plans, and only $5/month/site for Professional plans. Something Even Bigger is On the Horizon A completely new Snapshot type is coming to allow you to correctly migrate from Staging to Production, more easily and faster than ever before. This is a big deal. It allows normal, non-technical people to do things that previously took sysadmins and custom scripts outside of MODX Cloud—and tedious, time consuming, and delicate multi-step procedures inside of MODX Cloud. We use it internally for MODX Cloud content to cut down our migrations from Stage to Production from roughly half an hour to 5 minutes or less! If you would like a sneak peak and are on a paying plan, let us know by opening a support ticket and we’ll get you in line for early access. Stay Tuned for More Keep an eye here over the coming weeks—we can’t wait to share exciting updates to make MODX Cloud better for you and for your customers. [Less]

In Case You Missed It Website performance is important. Like, really important. Not only is it a nice thing to do for visitors of the websites you build, but Google is taking it more and more seriously as a factor for ranking on SERPs. Plus, we've ... [More] all heard those horror stories about how quickly the average visitor abandons a slow-loading page. Admit it, you do it too :P Pagespeed: Love It or Hate It You’re likely aware of the Google-made Pagespeed Insights tool, that tests the performance of your page. There are many other performance testing tools available, and actually some developers say that Pagespeed is not their favorite. However, most site owners and stakeholders seem to be familiar with Pagespeed, and therefore gauge the performance of their developer’s work on the Pagespeed score. Love it or hate it, Pagespeed is here to stay, and so the subject of this tutorial is: how to greatly improve your Pagespeed score in less than 25 minutes (real-time), using nothing but freely available MODX tools. Many Ways to Skin a…Potato Pets are humanizing. They remind us we have an obligation and responsibility to preserve and nurture and care for all life. ~ James Cromwell There are of course many ways to produce the same results demonstrated here. This is not an argument for or against any particular workflow, only a step-by-step guide on how to achieve great results with very, very little investment in time or money. It’s so easy, it’s a crime to not do it, in my opinion. Get On With It How to get your Google Pagespeed Insights score to 97, in less than 25 minutes, using free #MODX CMS tools. What are your favorite optimization tools and techniques? Please share them with the MODX Community, either in the comments here, in the forums, or the MODX Community Slack channel. [Less]

The latest release of MODX Revolution is a patch upgrade to 2.4.2. If you missed the 2.4.0 announcement, check out the details here. 2.4.0 was a big one. Highlights from the changelog: Add resource title in Manager Log for edited resources ... [More] Update Font-Awesome to 4.4 (note if you haven't voted for a MODX icon in FontAwesome you can do it here) Update setup to check the minimum supported PHP version ...and a bunch of UI improvements & 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.2 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): ​matdave​​, ​ilyautkin​​, ​inreti​​, ​zaigham​​, ​jpdevries​​, ​whitebyte​​, ​Jako​​, ​sergant210​​, ​argnist​​, theboxer​​, along with many other contributors who log & triage issues, review PRs, and commit code. The MODX Community is a Beautiful Thing. 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.3.x How to install MODX Revolution How to upgrade MODX Revolution Read the MODX Revolution Documentation It Takes a Village MODX is only as good as it is because of many individual community members and users that take the time to report issues and request new features. Make sure you read the documentation, post feedback and share your successes in the MODX community forums. On behalf of the entire MODX Team, Thank-you! [Less]

The latest release of MODX Revolution is a patch upgrade to 2.4.1. If you missed the 2.4.0 announcement, get the low-down here. Lots of goodies. Highlights from the changelog: Update PHPMailer to v5.2.13 Make user grid in ACL view consistent ... [More] with user group view Update xPDO to 2.4.1-pl Fix dropping elements in template [#12572] On policy template update sync policies with policy template [#12654] Restore backwards compatibility for addons interacting with modTransportProvider [#12633] 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.1 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): bezumkin, hansek, Mark-H, and theboxer, along with many other contributors who log & triage issues, review PRs, and commit code. The MODX Community Rocks! 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.3.x How to install MODX Revolution How to upgrade MODX Revolution Read the MODX Revolution Documentation It Takes a Village MODX is only as good as it is because of many individual community members and users that take the time to report issues and request new features. Make sure you read the documentation, post feedback and share your successes in the MODX community forums. On behalf of the entire MODX Team, Thank-you! [Less]