I tweeted about this yesterday and quite a few people were surprised, so it’s a good idea to repeat it.
If you run an ecommerce site on shared hosting, you can never be PCI compliant (because you’re sharing the server with other code, other users, you’re probably using FTP, etc).
Which ecommerce sites need to be PCI compliant? All of them.
Do you have a payment gateway that redirects offsite to gather CC info?
That’s nice, but it doesn’t exempt you from PCI compliance.
Malicious code could still present a fake form to the customer, or redirect to a fake url.
http://drupalpcicompliance.org is your friend, read the whitepaper today.
A 10$-20$ VPS still won’t make you PCI compliant, but it’s a step up in security and a giant step up in performance (since you get memcache/redis, solr…)
EDIT: Changed the conclusion to clarify that a VPS isn’t guaranteed to be PCI compliant.
A small group of students wants to learn PHP and use it to develop a small portal for a university project.
It should show best practices, and have the usual set of features (comments, a bit of ajax, sending an email, login / logout, a small admin panel).
They are already familiar with OOP through previous Java work, have learned the basic PHP syntax, and are now asking you how to proceed. A framework? Which one?
I was asked the same thing back in June, and I wasn’t sure what to answer. The last PHP frameworks I developed with were Zend Framework 1 (ugh) and CodeIgniter. Some research had to be done.
Making the choice
The basic requirements were:
- Modern PHP code.
This means PHP 5.3+, namespaces, PSR0, hopefully Composer.
- Decent number of users.
More popular frameworks have more documentation, StackExchange answers and other resources. They are also more likely to be useful later in the job market.
- Minimal and clear.
We wanted something that is easy to read and understand, approachable to a beginner.
After weeks of work Commerce License is finally up, as well as Commerce File 7.x-2.x to go along with it.
Commerce License provides a framework for selling access to local or remote resources.
In practice, this means that there’s a license entity, usually created during order checkout, that holds information about accessing the purchased resource, and it has a status and an optional expiration date.
This allows selling access to anything from files to node types, or perhaps ZenDesk tickets and accounts on remote sites, all using a common API, while always having a record of the purchased access.
At the heart of that API is the entity bundle plugin, which allows different license types to have different logic.
What is entity bundle plugin? The project page says only this:
This API module allow developers to build an entity type which is attached to strong behaviors.
That doesn’t help much, so let’s dive in. Let’s start by looking at how entities are built on D7.
We spend a lot of our time in the Drupal.org issue queues, working on bug fixes and adding new features. It’s an okay tool for organizing development, and we’ve grown used to its quirks by now.
Users also try to use the issue queues to receive support, with more or less luck (typically, the bigger the module is, the less luck they have).
And while it’s great to have the support request category to reclassify confused bug reports or already implemented feature requests, as an actual tool for support the issue queue is terrible and it hurts the community.
Recently I’ve made several remarks on Twitter about the pain of using the Features module for install profiles. Since they weren’t universally understood, I’ve decided to blog a bit about what is one of my pet topics: the problem of default configuration.
- An install profile / distribution needs to be able to export and provide default configuration (content types, fields, variables, etc).
- The user needs to be able to revert to default configuration when desired.
- The user needs to be able to “untrack” any piece of configuration, allowing it to be deleted.
- The user needs to be able to export and version his own export of the configuration, maintaining his changes across distribution upgrades.
The last two requirements are not satisfiable with Features, because Features has no concept of “default configuration” over regular configuration.
By now most of us have used a Drupal distribution.
Drupal.org takes a distribution’s drush make file, fetches Drupal core, contributed modules, themes, libraries, adds custom modules, and provides an archive that’s ready to use and install.
While distributions provide a great base for a site, we always need additional pieces (modules, libraries) in order to satisfy our use case.
So, how do we use a distribution as a starting point, and add our modules on top?
It’s been two and a half years since I last blogged.
Back then, I used an alpha version of D7 that didn’t even have imagefield working properly. In time, the installation became too annoying to remigrate (there was no upgrade path for pre-releases), and I decided that Twitter was a better medium for what I wanted to say, so I closed the blog.
Fast forward to May 2013, I’ve slowly filled up a queue of technical topics I want to discuss, so I’ve decided to reopen a blog. Also decided I want a hosted solution, but not Drupal Gardens, since I’m already very familiar with Drupal 7. Instead, I am giving WordPress a shot for the first time. It fits nicely with my efforts to get off the island this year, branch into other projects and work on new things. So far I’ve had a lot of fun playing and developing with Silex and AngularJS, as well as contributing to an oauth2 server library. The pull of Python is always strong, too. Fun times ahead, especially considering the approaching Drupal 8 and the many advances it brings.
So, here we go…