Howdy! Welcome to my humble web presence. I'm Mark Hamstra, the CEA at my latest venture modmore, where I spend most of my time developing and providing support for awesome tools and extras for MODX Revolution.

This website is where I share my thoughts, cool projects and other oddities related to MODX, xPDO and ExtJS. Sometimes I post three blogs in a day, sometimes there's no update in a year. Read a random article.

While working on adding a set of permissions to the ContentBlocks component, Isaac was wondering if there were any good ways of testing them out. The permission system in MODX is not very popular due to its (perceived?) complexity and the need to constantly flush permissions to see a result.

yeah, and the only reliable way i’ve found to test permissions in modx is to have one browser session with the admin changing permissions, and a separate session with the test user. and EVERY SINGLE TIME YOU CHANGE A PERMISSION, you log the test user out and back in ~ Isaac Niebeling

We had a bit of a conversation following that about how the ACLs work.

I had been using the Manage > Flush Your Permissions for refreshing permissions on my limited admin account. I simply made sure the limited user could access that, and that made my testing a lot easier than logging out and in again over and over.

That already seems like one step up, but can we do better?

It turns out that MODX has this thing called Stale Sessions. They've been introduced way back in 2.2.1 and their primary goal is to have a user refresh the "attributes" in its session (which contains a cache of many things about the user, including settings and permissions) the next time it requests a page.

I vaguely remembered that being there, but wasn't quite sure how it worked so I did a search across the MODX codebase to find instances of it, to see where it was called and how it affected the sessions. And that's when I stumbled across the processor for the Manage > Flush Your Permissions menu item.

As the name indicates, the Flush Your Permissions action will to flush the permissions of the user that is logged in. It even warns you that it doesn't affect other user sessions.

But that's a big lie.

The Flush Your Permissions processor isn't restricted to a single user. It tells all users to reload their permissions, through the Stale Sessions feature introduced in 2.2. Seriously, just check the source code if you don't believe me, there's no mention of the current user.

Following this discovery I did some testing with my new set of permissions for ContentBlocks, and indeed flushing the permissions for a full admin user also affected my limited admin user in a different browser.

Magic!

The commit that introduced this behaviour back in 2012 mentions that it doesn't yet affect anonymous sessions, as those don't have a user record that instructs them to refresh their session, so that's a bit of a caveat if you're working with ACLs for site visitors. But when tweaking client access to the manager, using Flush Your Permissions instead of logging out and back in is going to save you a lot of time.

Can we do better?

So aside from this being a time saver, is there anything else we can do with this information?

Well, one of the reasons I started looking into this was to see if there might be a way to make MODX automatically flush relevant sessions when access policies are changed or added to a user group.

I had concerns about practicality because it could take a long time on large sites, but some tests of the flush permissions feature seem to indicate that it's only a few hundred milliseconds even on sites with thousands of users. That seems totally acceptable for the convenience of not having to flush permissions manually in a lot of cases.

It turns out, the core is already doing this, but only when creating a user group using the access wizard. Not when updating a user group, or when a policy is added, updated or removed.

Sounds like some pull requests may be in order.


Read 0 comments and share your own thoughts!

I don't know

I don't know.

When you think of entrepreneurs that make a name for themselves like Elon Musk, Steve Jobs or Derek Siver, those three words don't really come to mind.

While my goal is not to be world famous, a best seller author, or the first person to drive a ridiculously good electric car on Mars, I do want to hone my skills as an entrepreneur. Build products and services that people enjoy using, and growing a business doing things I like.

Yet all so often, I just don't know.

What's the best way to deal with problem X? How do we, or should we, work towards accomplishing Y? What will the effect of decision Z be? Yes or no?

There's uncertainty around every decision that needs to be made. And that freaks me out.

What if we did this one thing? What if we didn't? Will it be the beginning of the end, or is it the start of the famed hockey stick?

By surrounding myself with clever people and actively seeking their feedback I try to minimise the risk of doing something incredibly stupid. I try to force myself to take some time to really think something through if there's serious push back from people that know what they're talking about. More often than not, I change my position on said idea or decision. Maybe it's not quite as good as I first thought, or this just isn't the right time or place.

Stupid self confidence makes me wonder though if I'm a bad entrepreneur for not being 100% sure. How can you run a business if you don't know how you want to move forward on a simple decision?

I've learned to accept that it's okay not to have all the answers. It opens up an idea to more objective look. By saying I don't know, it doesn't mean that I don't care or that I don't lean a certain way, it's just that it needs further thought, analysis, time, or all of the above.

I think that's a good thing.

Free development licenses for Premium Extras at modmore is one of the things in the I don't know category that made it through to an actual launch. The first responses when I proposed this in a team meeting were cautiously optimistic. And when it was first mentioned at the MODXpo, only a few days later, people responded with a round of applause.

Now that it's live, people are starting to take advantage of it. Over 250 free development licenses have been installed to date.

So far, it seems to be a popular decision.

But will people install our paid-for extras for free, tear out our license system, and cause modmore to go bankrupt? Or will this lower the barrier to entry to the point that we will see an influx of new users and increased sales with it?

I still don't know.

But I'm cautiously optimistic.


Read 3 comments and share your own thoughts!

One of the areas I'm focusing on for Commerce is building a webshop solution that is testable. With a suite of automated unit, functional, and mutational tests, you can make sure that code works as expected at all times. I've written about this before.

Opponents of testing often see it as something that takes a lot of time and effort (which is true), and that makes it expensive to do. An immediate return on investment is also rare, so automated tests are often pushed back or just skipped entirely. While I’ve been convinced about the merit of testing, I too fall into this trap and have yet to achieve the magical 100% test coverage on any sizeable project.

Unfortunately, especially when it comes to e-commerce, the cost of not properly testing every aspect of the code can be very real.

Take the modmore.com billing engine for example. It has been working pretty well for the past three years. I’ve done plenty of manual testing on my local environment to make sure it works as expected when making changes. I just haven't made the time to add unit tests to it, partly because not all the code is as easy to test.

Last weekend I was working on getting the documents in order for the first quarter taxes and shipped it all off to my accountant. Pretty satisfied with the quarterly results, I went on my merry way to do other stuff that didn’t involve looking at numbers and invoices. Until I got an email back from my accountant today about a discrepancy he noticed.

It turns out that there was an issue fetching the current VAT rates for the EU member states from a remote service. Previously we were fetching that over HTTP, but the service started requiring HTTPS, which resulted in a failed connection and the error handling wasn’t sufficient to cause alarms to go off about a critical issue.

Because of this issue, 44 orders which should have incurred 19-21% VAT, ended up being charged a 0% rate. As I still have to pay the VAT that should have been charged, that means I have to pay over €400 in VAT out of own pocket.

Look, it's an info box about VAT!

If you aren’t sure what VAT is or how it works, here’s a high level summary of how it works, at least in the Netherlands.

A business charges you the appropriate VAT rate. The rate depends on the type of product and the country. The standard rates in the EU range between 17% (Luxembourg) and 27% (Hungary), but there are reduced rates for special types of goods and services. When selling to customers the price mentioned is typically inclusive VAT, in business-to-business prices are usually exclusive VAT; this may vary per country though.

At the end of the quarter, the business owner or accountant tallies up the amount of VAT they had to charge their clients, and deduct from that the amount of VAT their suppliers charged them. The resulting number is the VAT they have to pay to the tax office. This is why it’s called Value Added Tax; the tax is paid over the value you’ve added (difference between cost and sale price).

At modmore we don't have a lot of direct costs for selling our products, so we end up paying most of the charged VAT to the tax office.

Luckily this only affected a relatively small slice of our orders and overall revenue from the past quarter. It won't put us out of business or anything, it just lowers the profit margins for those orders by a considerable amount.

But what would have happened if we had ten times as many clients, and we were talking about a €4000 charge instead? What if it applied to all orders instead of less than 20%? What if my accountant didn’t notice the discrepancy and the problem would only have been discovered after six months? A year? What if a client were to rely on the same code for a webshop with hundreds of thousands of orders each month?

Suddenly spending extra time on automated unit, functional and mutation testing sounds like a great investment. Now if you’ll excuse me, I’ve got some more tests to write for Commerce...


Read 2 comments and share your own thoughts!