Agrégateur de flux
There are a number of use cases in which you want to supply visitors of your website with a simple means of paying, but where full-blown webshop implementations like Drupal Commerce or Ubercart would be overkill because you do not really need products and order management.
Luckily, there is a light-weight solution for this by using the Webform paymethod select-module in combination with the Payment-module and one or more modules which supply payment providers. In this blog we will be using the Ogone-module.
By the way: Ogone changed its name to Ingenico and therefore exactly speaking we should be using the Ingenico-module. This module however is exactly the same as the Ogone-module, only a search-replace was appiled which changes 'ogone' to 'ingenico' in all module code, and (wrongly) even in the documentation links supplied.
Because the patch we have to apply later on was written for the Ogone-module we will use that module and not the Ingenico. And everywhere where I've written "Ogone" you should apply a search-replace to "Ogone/Ingenico" in your head.Contrib modules
Setting up webforms to include simple payments requires a number of contrib modules to be enabled:drush en -y webform_paymethod_select drush en -y ogone
NB: Use "drush en -y" to make sure all dependencies are installed.
You will also need to make a number of configuration steps before you can use webforms with payments.Configure payment method
To add a payment method. As explained above we are using the Ogone payment provider here, so all fields used below will be Ogone specific but other payment providers will have similar fields.Add an Ogone payment method Title (specific)
Basically this is the admin label.Title (generic)
This is the label shown to customers.Owner
This defaults to the user who creates the payment method but can be set to a other user. In combination with setting the permissions correctly this will give the selected user the ability to fully control the payment method.PSP ID
This is the ID provided by the payment provider to you. You also use it to log in to your Ogone pages on the Ogone backoffice login so I assume it will be known to you. If not: you will absolutely need this to get the payments working.Passphrase hashing algorithm
You have a number of choises here:
But the important thing to remember is that whatever you choose here must also set on the Ogone page Configuration | Technical information | General security settings. Failing to do so will give errors because the encryption/decryption of sent information will fail.Incoming passphrase and Outgoing passphrase
These password form the heart of your security settings and must always be kept a secret. Furthermore: if you are an external developer who is configuring the payments for a client it will be best practice to make the client change these passwords and the password for the Ogone backoffice after the testing period.
In this way you will not have acces to the payments made, and this is something the client really wants (not that they are not trusting you of course...).
But seriously, you do not want that this kind of information to fall into the wrong hands when, for example, your development machine is hacked (Never!!) or stolen and in the latter case the hacker in one way or another succeeds in decrypting you hard drive (you do use an encrypted hard drive, don't you?).
The passphrase you give for Incoming passphrase must also be set on the Ogone page Configuration | Technical information | Data and origin verification. If there is a mismatch between these you will get an unknown order/1/s/-error in the Configuration | Error logs.
The passphrase for Outgoing passphrase must be set on the Ogone page Configuration | Technical information | Transaction feedback. And while you are there: do not forget to set the checkbox for I would like to receive transaction feedback parameters on the redirection URLs. If you do not check this box there will be no return parameters what so ever (not even the ones Ogone says are always returned) and the Payment module will generate an access denied error when the customer returns from Ogone.Server
When setting up payments you will always use the Ogone testing environment. Setting this wrong will give you an "unknown order/1/s/"-error in the Ogone error logs. Make sure this setting is correct and tested when the payment webforms are released to the production environment! And when all is correct force your client to change the passwords mentioned earlier.
By the way, there are a number of test-credit cards you can use on the testing environment:
- VISA: 4111111111111111
- Master Card: 5399999999999999
If you use either of these you can fill in any name, expiry date and security code you like and, great advantage, your real credit card will not be charged!Ogone payment method brand
If you do not make any choice here the customer will be presented a list (well actually a number of icons) when she arrives at the Ogone payment page. If you Ogone subscription offers mutliple payment method (for example VISA and Mastercard) leaving this empty will be best. Or you could add multiple payment methods in Drupal, each specific for a payment mehod in Ogone, and let the customer choose before redirecting her to the Ogone payment page.Enable the payment method
Do not forget to make sure that the checkbox "Enabled" on top of the payment method add form is checked. Ohterwise the payment method will not be avilable in the webform.Add a webform
To enable payments on the webform you will need at least a field of the type Payment Selector. When you add this you will need (aside the default fields like 'Label', 'Form key' etc) to select the following items:Payment Description
A short desctription.Selected Payment Methods
Here you have to indicate which payment methods will be available for the customer. If you enable multiple payment methods the customer will have to select which method she wants to use. If you enable only one payment method this one is used automatically and no options are presented to the customer. In some themes in this case an empty fieldset will be shown. The cleanest way would be a hook_form_alter to move the content out of the fieldset, but you could also remove the border and hide te legend in CSS.Select a currency code
The currency code is independent of selected payment method which makes it possible to use the same payment provider for multiple currencies.Line items
Each line item represents one item the customer will be paying for. In the most basic setup you can set a fixed amount and quantity, which means every payment made through this webform will be for the same amount.
More interesting however is the possibility to select the amount and /or the quantity from an other webform element. This will make the amount payed dependent on the choices made by the customer in the rest of the webform fields. You have to make sure that the elements do have a valid number as value, so selecting a default 'Textfield' here is not a good idea. Limit yourself to either form elements of the type 'Select options' or 'Number' to make sure you have a valid number for both the amount and the quantity. Not that you don't trust your customers of course...
For each line item you have to set the tax rate and the description.So, to review:
- You can either let the customer choose a payment method or make sure there is only one.
- Currency set here applies to all payment methods and all line items
- Tax rate and description are set per line item
I think it is best practice to include a required e-mail field to the webform and configure the webform is such a way that the customer also receives an e-mail with the data from the webform submission.
Also alway sent an e-mail to an administrator which, besides the filled-in webform fields. also includes a link to the webform submission.It is imoprtant to so because the submission ID (eg. '76' in /node/5239/submission/76) is also used as the Merch ref in the Ogone overviews. So if you have this number you can always track the payment in Ogone, even if by some distater you have to revert your site to an earlier backup or have to reinstall the complete site.
By the way: if this should ever happen, do not forget to set the Next submission number of each payment webform hight enough to not overwrite any exsiting payments. You can do this on the edit form of the webform, under Form settings | Advanced settings.
If you do this however, make sure you also do the same calculations serverside by adding an extra submit handler with a 'hook_form_alter' and in store the calculated amounts in the$form_state['values']['submitted'][<element_name>]
Ok there's a couple of things to do before you can get this working.Ogone parameters
Ogone changed the parameters included in the feedback somewhere in 2015 and since the security SHA included in the feedbackt request is based on this parameters and access to the payment result pages is calculated by comparing the sent SHA with a calculated value, you wil get an access denied when returning from Ogone, see the function ogone_return_access() in the file ogone/ogone/ogone.module of the Ogone-module. Luckily, there is a patch for this, wich updates the parameters used in the computation.
Of course somewhere in the near future this patch (I assume) will be included in the stable verison of the Ogone module, but if you get access denied errors and you are sure the pass phrases are entered correct on both the Drupal and the Ogone side, this is a thing to check first.Webforms says no...
After applying the forementioned patch and testing another payment, you wil get an... Access denied. But this access denied is not thrown by the payment modules but by the webform-module. The problem is caused by the fact that the payment module is not yet ported to webform 4.x, the default webfom version you get when installing the webform-module.
The solution is however reasonably simple: the 4.x branch of webform uses a token to determine if the visitor has access to the requested form submission. All we have to do is to add the token to the parameters the payment module sents to Ogone (or any other payment provider). The patch for this can be found here. If any access denied-error are thrown, make sure to check if this patch is include in the module you are using.Ogone says no...
Sometimes there will be an error direclty when the customer lands on the Ogone payment page. There are a number of settings in Ogone to check when this happens. First of all: re-check the pass phrases are indentical and you have not swapped the ingoing and outgoing passphrases.
Also check on the Ogone pageConclusion
The Irish Drupal community is delighted to welcome you to DrupalCon Dublin and offers you a “céad míle fáilte” - a “hundred thousand welcomes”!
We hope you are looking forward to DrupalCon Dublin as much as we are. It's looking like it will be a fantastic event with lots of great sessions lined up, Trivia Night and of course, the Drupal Ireland Welcome Party!
How to bring your conversion to top? The very interesting subject of optimization was again a huge topic at this year’s conversionSUMMIT. Is it as easy as experts say? We summarized our thoughts about it in this article.
Today, debhelper 10 was uploaded to unstable and is coming to a mirror near you “really soon now”. The actual changes between version “9.20160814” and version “10” are rather modest. However, it does mark the completion of debhelper compat 10, which has been under way since early 2012.
Some highlights from compat 10 include:
- The dh sequence in compat 10 automatically regenerate autotools files via dh_autoreconf
- The dh sequence in compat 10 includes the dh-systemd debhelper utilities
- dh sequencer based packages now defaults to building in parallel (i.e. “–parallel” is default in compat 10)
- dh_installdeb now properly shell-escapes maintscript arguments.
For the full list of changes in compat 10, please review the contents of the debhelper(7) manpage. Beyond that, you may also want to upgrade your lintian to 2.5.47 as it is the first version that knows that compat 10 is stable.
Filed under: Debhelper, Debian
I guess many new packages are added to repo, but disk usage is not so much. Why?
It provides a possible fallback in situations where Sys.timezone() fails to determine the system timezone. That can happen when e.g. the file /etc/localtime somehow is not a link into the corresponding file with zoneinfo data in, say, /usr/share/zoneinfo.
Duane McCully provided a nice StackOverflow answer with code that offers fallbacks via /etc/timezone (on Debian/Ubuntu) or /etc/sysconfig/clock (on RedHat/CentOS/Fedora, and rumour has it, BSD* systems) or /etc/TIMEZONE (on Solaris). The gettz micro-package essentially encodes that approach so that we have an optional fallback when Sys.timezone() comes up empty.
In the previous paragraph, note the stark absense of OS X where there seems nothing to query, and of course Windows. Contributions for either would be welcome.
There are many online sites that accept reading input from remote locations. For example a site might try to extract all the text from a webpage, or show you the HTTP-headers a given server sends back in response to a request.
If you run such a site you must make sure you validate the schema you're given - also remembering to do that if you're sent any HTTP-redirects.
Really the issue here is a confusion between URL & URI.
The only time I ever communicated with Aaron Swartz was unfortunately after his death, because I didn't make the connection. I randomly stumbled upon the html2text software he put together, which had an online demo containing a form for entering a location. I tried the obvious input:file:///etc/passwd
The software was vulnerable, read the file, and showed it to me.
The site gives errors on all inputs now, so it cannot be used to demonstrate the problem, but on Friday I saw another site on Hacker News with the very same input-issue, and it reminded me that there's a very real class of security problems here.
The following link shows the contents of /etc/hosts, and demonstrates the problem:
The output looks like this:.. 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost 127.0.0.1 stage 127.0.0.1 files 127.0.0.1 brettt.. ..
(Actually the actual output all newlines had been stripped. Weird.)
Despite reporting the problem to the author on Friday, and following up the report via Twitter this has not yet been fixed, but after four days I assume I'm not alone in spotting this.
From "Stop stealing dreams":
«Settling for the not-particularly uplifting dream of a boring, steady job isn’t helpful. Dreaming of being picked — picked to be on TV or picked to play on a team or picked to be lucky — isn’t helpful either. We waste our time and the time of our students when we set them up with pipe dreams that don’t empower them to adapt (or better yet, lead) when the world doesn’t work out as they hope.
The dreams we need are self-reliant dreams. We need dreams based not on what is but on what might be. We need students who can learn how to learn, who can discover how to push themselves and are generous enough and honest enough to engage with the outside world to make those dreams happen.»
This made me think that I know many hero stories based on "the chosen", like Matrix, like most superheros getting powers either from some entity chosing them for it, or from chance.
I have a hard time thinking of a superhero who becomes one just by working hard at acquiring and honing their skills: I can only think of Batman and Ironman, and they start off as super rich.
If I think of people who start from scratch as commoners and work hard to become exceptional, in the standard superhero narrative, I can only think of supervillains.
It makes me feel culturally biased into thinking that a common person cannot be trusted to act responsibly, and that only the rich, the chosen and the aristocrats can.
As a bias it may serve the rich and the aristocrats, but I don't think it serves society as a whole.
RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding and serialization library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects.
This version contains a contributed bug-fix pull request covering conversion of zero-length vectors, and adding native support for S4 objects. At the request / suggestion of the CRAN maintainers, it also uncomments a LaTeX macro in the vignette (corresponding to our recent JSS paper paper) which older R versions do not (yet) have in their jss.cls file.Changes in RProtoBuf version 0.4.6 (2016-09-08)
S4 objects are natively encoded (also PR #18)
The vignette based on the JSS paper no longer uses a macro available only with the R-devel version of jss.cls, and hence builds on all R versions
CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.
…what we need is a tool that allows modules or profiles to optionally install content after their other setup steps
It’s never just the direct application X or feature Y that gets added. It’s the tools that enable X or Y that get added to core. And for a long time this generalized approach was considered enough.
What’s changing is that on top of the enabling tech we now strive to also add a more opiniated example, a more concrete and specific expression of those new capabilities. I’m reminded of of Stevey’s Google Platforms Rant: “A platform needs a killer app.”
It’s interesting to see this shift in balance and I’m curious to see how it will play out.Tags: drupalproductframeworkdrupalplanetSub title: A platform needs a killer app
A year ago I got tired of Jenkins and wrote a CI system for myself, Ick. It's served me well since, but it's a bit clunky and awkward and I have to hope nobody else wants to use it.
I've been thinking about re-architecting Ick from scratch, and so I wrote down some of my thinking about this. It's very raw, but just in case someone else might be interested, I put it online at ick2.
At this point I'm still thinking about very high level concepts. I've not written any code, and probably won't in the next couple of months. But I had to get this out of my brain.
Greetings from the DrupalCon Events Team, we have a few programming updates to share.
For the past few years we have been thrilled to offer live streaming of the DrupalCon keynotes and closing sessions. Unfortunately, we will not be live streaming these sessions in Dublin. To catch the action live, you will need to meet us in Dublin. The good news is that we have a top-notch archiving crew who will archive these sessions as quickly as possible.
Another year, another OMGWTFBBQ. By my count, we had 49 people (and a dog) in my house and garden at the peak on Saturday evening. It was excellent to see people from all over coming together again, old friends and new. This year we had some weather issues, but due to the delights of gazebo technology most people stayed mostly dry. :-)
Also: thanks to a number of companies near and far who sponsored the important refreshments for the weekend:
As far as I could tell, everybody enjoyed themselves; I know I definitely did!
We got a few shop owners together at DrupalCamp LA 2016, at UC Irvine to talk Drupal. This is Part 1 of 5 of that conversation, talking about using Drupal 7 or Drupal 8 for new projects that we’re building.Read more...
Keep a good performance while storing logs on your Drupal database.Fri, 2016-09-09 15:20By salva
In the world of Drupal, it's a common and best practice to disable the Dblog module (Database logging) on production sites, in favour of using the Syslog module, which will take care of logging all php errors, notices, or any custom log messages into the Unix system logs, removing the performance burden of writing them to the Drupal database.
There are scenarios in which this approach, while convenient to keep the site running smoothly, is rather problematic when troubleshooting issues that appear only in a given environment and under very specific conditions. For those, unless you can count with some custom logging system built for very specific aspects of a site, you are pretty much blind and unable to find the source of a bug.
We've recently had this problem in one of our sites, where several external systems were involved in the feature that we were trying to debug. Given that those systems couldn't be reached from a development environment, we needed a minimum amount of information to be kept on the Drupal database, so that it was easier to navigate and see the details than it is to sail through the syslog. For that, Pascal Morin wrote a new module called Selective Watchdog Backend (selectlog).So what's it?
The concept behind the Selective Watchdog Backend is quite simple: instead of sending all logs to the syslog, give developers some flexibility to choose what can be also sent to the Drupal database. That way, you ensure that everything is sent to the syslog as usual, but for very specific sections of your site, you still have a meaningful set of logs of what you might consider more important at any given point. The great thing of the module, is that it doesn't affect any other watchdog modules you may be using. It's just an addition on top of them.
Let's see a couple examples, of what could be common use cases:
Scenario 1: You have a complex integration with a 3rd party API, and all the site users make constant use of it. However, it's not very stable, and you need to assist your client by providing them with exact details of the points at which the API is failing to return the expected results. Of course you've already added watchdog entries for these cases when you wrote the module, because you're a smart developer, but now you need these entries to be surfaced on the Drupal site. With the selectlog module enabled, all you'd have to would be editing your settings.php file and add these lines:
$conf['selectlog'] = array( 'dblog' => array(
'your_api_integration_module' => '*',
That would log every watchdog entry of your custom module to the database, making it available under admin/reports/dblog.
Scenario 2: Some of your views are breaking on production and you don't manage to find the problem (this is less likely to happen, but it'll do for the sake of the explaining the module usage). To troubleshoot this, you want to store the watchdog entries from the views module in the database, but just those of a certain severity. To do so:
$conf['selectlog'] = array( 'dblog' => array(
'views' => array(
And that's it. Pretty neat and convenient. Hopefully we'll be promoting this sandbox to a full project soon. In the meantime, take our word that it works wonderfully. If you think it's going to be an useful feature on your site, I recommend checking out the details on the project page or the comprehensive README.md file included with the module. Enjoy your logs!
BlogViewport module ready for Drupal 8 BlogSpinning up a CentOS server for Drupal FAQHow do I find Drupal messages with the syslog module enabled? BlogDoing more with Drush sql-sanitize
Time to check out one of our favourite contrib modules for Drupal - The Coffee module. With a keyboard shortcut it displays a quicksearch moodal window that lets you navigate around in Drupal very quick and easy.
Every year since 2010 the Whitley Bay Film Festival has put on a programme of movies in my home town, often with some quirk or gimmick. A few years back we watched "Dawn Of The Dead" in a shopping centre—the last act was interrupted by a fake film-reel break, then a load of zombies emerged from the shops. Sometime after that, we saw "The Graduate" within a Church as part of their annual "Secret Cinema" showing. Other famous stunts (which I personally did not witness) include a screening of Jaws on the beach and John Carpenter's "The Fog" in Whitley Bay Lighthouse.August 14, 2016
This year I only went to one showing, Fritz Lang's Metropolis. Two twists this time: it was being shown in The Rendezvous Cafe, an Art-Deco themed building on the sea front; the whole film was accompanied by a live, improvised synthesizer jam by a group of friends and synth/sound enthusiasts who branded themselves "The Mediators" for the evening.August 14, 2016
I've been meaning to watch Metropolis for a long time (I've got the Blu-Ray still sat in the shrink-wrap) and it was great to see the newly restored version, but the live synth accompaniment was what really made the night special for me. They used a bunch of equipment, most notably a set of Korg Volcas. The soundtrack varied in style and intensity to suit the scenes, with the various under-city scenes backed by a pumping, industrial-style improvisation which sounded quite excellent.
I've had an interest in playing with synthesisers and making music for years, but haven't put the time in to do it properly. I left newly inspired and energised to finally try to make the time to explore it.
There has been some movement of late around adding some default content to the standard profile.
This was originally reignited by Roy Scholten in his getting something in the box post.
As author and co-maintainer of the default content module for Drupal 8, I wanted to share my thoughts on the potential of adding it to Drupal core.
At long last, the copy editing of the User Guide is done! (If you've been a member of this group for a while, you should know what I'm talking about; if not, go browse the archives at https://groups.drupal.org/documentation for the last 1.5 years or so). I'd like to thank everyone who helped with editing tasks, and especially Jojy Alphonso (jojyja), who did the vast majority of the copy editing. THANK YOU!
So, the guide is in very good shape, and I just made an official release of version 8.x-2.0, corresponding to Drupal Core 8.2.x (which is supposed to be released soon). It should be live on Drupal.org soon, in HTML format, for your reading pleasure (not sure exactly when, since the reduced Drupal Association staff is pretty busy, but we're working on it). I'll post a link in a comment here when that happens.
Meanwhile, you can go to the User Guide project page and download the release, which contains all of the source files (which are written in AsciiDoc markup language), as well as PDF, ePub, and Mobi ebook versions (those are in the "ebooks" folder/directory of the archive you get when you download the project).
Also... The next step will be to translate the User Guide into other languages. The enthusiastic and experienced Catalan and Hungarian language teams will be starting on that shortly, and refining the process so that hopefully the other language teams can get started soon as well. If you want to help translate the Guide, you should start by joining the translation team on https://localize.drupal.org for your language. Thanks!