Feed aggregator

Lessons Learned in Scaling Agile

Lullabot -

“Be like water, flow.” - Bruce Lee

Being agile (note agile with a lower-case a) is not about sticking to a prescribed set of principles or methodologies. It’s about minimizing the prescribed set so that you focus on adapting to change. One of the biggest lessons to impart here is that you need to be agile in the sense that you can adapt to how your client works, but not give up on the course you feel is more “right” when you sense something needs to change.

Throughout this piece, you’ll note that I advise against certain things, but I also encourage you to understand the “why” behind your client’s motivations. I tend to be judgemental of client processes when they’re not as efficient as the ones I’m used to, but I also understand that not everything can be improved overnight.

I hope to illustrate how even when you come up against adversity and difficult situations it helps first to take a step back and relate to the client, understand the difference in values, and then try to be the mediator between those opposing values.

The Gig

Not so long ago we were part of a project in which the company decided that they wanted their Scrum teams to adhere to the Scaled Agile Framework and began rolling that out across their organization. Everyone got a JIRA license, a Scrum Coach was added to the team, and they split up into cross-functional teams. The teams were comprised of multiple Product Owners and their direct reports—almost all of whom worked on multiple projects. Lullabot was brought into the mix to help out on just one of these projects: the website.

Before continuing, I’d like to take a moment to reflect on the irony that presents itself when looking at the complexity illustrated in this graphic from the Scaled Agile Framework in the context of the word “agile.” I guarantee this is not what the founders of the Agile Manifesto had in mind.

undefined

Compare this to the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Upon introduction to the client, we found that there was a fairly extensive Backlog for the website project already written up as User Stories. Many of these User Stories were incomplete, and there were no other written requirements or specifications though the Product Owners possessed this knowledge and could answer questions we had about a given Story.

Soon after we started, our client’s upper management assigned the team a Scrum Coach from an outside consultancy. Part of the coach’s job was to sit in on our meetings and listen to how the projects were being run and to make suggestions on what should change about how the meetings were run and the projects planned out to adhere to the Scrum methodology.

Longer meetings resulted—some six hours long—in which all members of the team were present to groom the Backlog and plan our Sprints. Sprint iterations grew from two-week intervals to three. Time was spent going through the priorities of the Product Owners, the subsequent User Stories that represented those priorities, sizing the User Stories with Story Points, and planning which Sprint they would go into. Discussions consisted of what Tasks were necessary to accomplish a given User Story, and then estimating the Tasks.

Eventually, as we started to write better User Stories and, in turn, gain a better understanding of the work, we were able to get ahead of the meetings. We planned out the tasks ahead of time for the priorities that were set and the meetings became shorter and shorter.

Through all of this, I gained some significant insight into our client’s company and how it works. I also gained a better understanding of how the Scrum methodology can fit into a larger corporation, and where it does not. I learned where it makes sense to diverge from the process and where it does not. Here are some of my key takeaways from this experience.

Multiple Product Owners on a Scrum Team is Hard

We’re used to just one product being worked on by a team, but our client had a different structure where the team was cross functional and worked on multiple products at once as well as supported them. Since there were multiple products, there were multiple Product Owners. Each product had a team, but each team member was responsible for multiple products, resulting in divided attention, and sometimes diverging priorities. After working in this way, it’s become clear that it is more ideal, if not practical, to have a team dedicated to one product. Multiple product owners was the key factor in why our Sprint Planning meetings lasted so long. We weren’t planning out what we were going to work on for just one product, but for many.

Competing Priorities

With multiple Product Owners on a team, there is competition for resources and priorities. Which product comes first? Which task for which product does an individual work on first? A developer now has multiple Product Owners to report to, and that means direction from more than one person, which can be confusing and frustrating. More time is spent discussing these priorities and balancing them than if you just had one product and one Owner.

Balancing the Work

Even though teams can be pretty cross functional, the cross functionality is not always completely balanced. Some people have more knowledge about one system than another and so are more suited to that work. Or perhaps—as in Lullabot’s case—you’re an outside vendor only working on one project. If your overall team already has a target for your maximum amount of story points you can have within a sprint, and most of those points are allotted to a product that is unrelated to your work, you end up with a number of story points that may be less than what you can actually handle for a given sprint for your product. In short, it becomes difficult to make sure everyone has enough work to last them through the end of the sprint. The team spends more time trying to balance the work than doing the work.

In a truly agile scenario, you respond to the needs of the client, and to the bandwidth of the developers. If a developer runs out of work, you can pull that work and begin—not sit around waiting for the end of the sprint—without repercussions.

Estimating the Work

With multiple areas of expertise and responsibilities, it takes more time to estimate the work because the goal is to have everyone understand the work being estimated. Estimation sessions should be limited to just the people with the appropriate knowledge, and as more people become familiar with the work they can lend their input, but time is wasted having people in a meeting who don’t understand the work. That person also tends to feel devalued because their time is being wasted.

For instance, in this case, we have multiple products being worked on. In a sprint planning meeting, we have members of each product. Lullabot is one of them, but we’re only part of one product. So while estimation is happening around issues that are relevant to Lullabot’s work, the people in this meeting who have no work at all on the same product are having their time wasted and feeling devalued. By having sprint planning meetings around just one product at a time, you can have only the people who are relevant to the discussions in the meeting and avoid wasting anyone’s time.

People over Process

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” This resonates with Lullabot’s values—especially Be Human. If a process isn’t working, we change it. We are always on the lookout for opportunities to make more valuable use of our time—Lullabot’s brand of continuous process improvement. Our affinity for efficiency extends to everything we do—whether that’s designing our processes, coding a migration to run as fast as possible, or optimizing the page load of a website. How does that relate to being human? It shows how much we care about our people. We value their time. 

Since our first reaction to tedious processes is to cut them up and change them around, it was difficult to keep from trying to change this client’s processes. Considering the client was just starting to understand how Scrum works and to get the various Ceremonies into place, we felt it was more prudent to resist our typical reaction of trying to optimize the processes early on. They were already changing their existing process and had a guide in the form of a Scrum Coach to help them understand and implement this new way of working. Any changes to this process would have been more of a hinderance at this point. We’ve been through this before and can seemingly see into the future around this and where things would need to change to make them more efficient, but without a solid understanding of the Scrum Methodology first amongst the various team members, our words would fall on deaf ears which were already focused on the changes at hand.

“Progress is impossible without change, and those who cannot change their minds cannot change anything.” - George Bernard Shaw

Focusing on helping people understand the changes to their process was where we decided it would be best to spend our time. We let them know that certain things may take a bit longer this way, but we were dedicated to the team learning the new process and adhering to how they wanted to work. In this we established a base of trust and knowledge sharing, helping to position ourselves as experts. We kept the process optimizations in our back pocket for when the team was more solid and knowledgeable and could then make more educated decisions about which processes should change, and which ones should adhere to the typical Scrum methodology being implemented. With an understanding of what work may suffer because of this restructuring, we were now free to focus on the relationship and to meet the expectations of our Product Owner.

In this way, we didn’t take our typical approach of changing the process to help our people, but instead focused on helping people understand the process. People understanding the process was the way Lullabot could put the people first and optimize the process later.

Create more Value than you Receive

One of the challenges in working with an inefficient process that cannot be changed is that you’re directly violating that value of efficiency that we hold so dear. When a value is violated, even for a short time, feelings of guilt and remorse set in. If this continues unchallenged and unchanged, apathy can result. You begin not to care about your work because you know you cannot make it as valuable as you know it could be. We want to avoid apathy at all costs. So how do we avoid it when there seems to be nothing we can do, or we’re too tired to continue fighting for our values

A poignant reminder came from one of our Lullabots facing a similar situation. 

“…this is a necessary first step in a process, [and we] need to work toward activities that [the client] can look out the window and appreciate…”

This spoke to the need of going through these hoops while the company reorganized the way it works, while continuing to strive to find those areas in which Lullabot has become known for improving any project. By sticking to our values and sharing them with others through our work and our daily interactions, we can slowly but surely improve not only the projects we work on, but the relationships and by extension the entire team.

Putting such a value on hold even for a short time is difficult, so we’ve tried to find ways to balance it out. Participating in other more lenient projects, passion projects, and taking ‘mental health’ days are just some of the coping mechanisms we employed. But building trust and establishing a solid foundation for your relationship at the beginning is important. Don’t give up on trying to make positive changes to the project, but be patient instead of pushy. Establishing that base will lead to the conversations that need to happen to make your situation better.

Process for Process Sake

Another value of ours as developers is simplicity. We strive not to create complexity for its sake. And when a process is complex, it’s a double whammy. To cope with a tedious process, it helps to understand its origins. You might still resent that it’s a complex process, but at least you’ll understand the thinking behind it, if not the need for it. If you still don’t understand, then perhaps there is room for change. But you have to understand it first to change it.

We advise against doing any process just for the sake of the process in any situation. Strive to understand the why behind the processes being put into place, especially if you think they don’t make sense. In our case, there was always a factor that we weren’t seeing. Typically that factor had something to do with a side of the client’s business that we simply did not fully understand at the time. After it was explained, it became apparent why a process was so complex and why the complexity was deemed necessary. That doesn’t mean we don’t still strive to reduce the complexity. In fact, we look for every opportunity to reduce complexity wherever we see it. 

Be Truly Agile

Agility can come in many forms. Agile with a capital “A” has become a “thing” in the business world and in the software world that has connotations that are starting to change the meaning of the word—for some in a negative manner due to the a number of meetings and process overhead that can result. Being truly agile—with a lowercase “a”—is a thing of rarity and beauty. Be “agile” in the sense that you are nimble, quick, and alert. Be agile in the sense that you can respond quickly to change but also agile enough to recognize when it isn’t yet time to change a process. Seek to understand first, recommend changes second. Learn about the subscribed Agile methodologies that are out there, and be agile enough to adapt them as necessary to fit the needs of your project.

Drupal Association News: Membership is connection

Planet Drupal -

Today we launch the membership campaign focused on the Drupal Association Community Cultivation Grants program. Association members fund grants to kickstart community-strengthening projects around the world.

The campaign runs through October 28 and our goals are 265 new members signed up and $10,918 in revenue. These are a 10% increase over the same period of time last year.

We'll have a banner on drupal.org throughout the campaign and a landing page. In it, you'll read how grant recipients feel connected in the community.  Their pride shows in their words about work on Drupal camps and a traveling roadshow. Thanks to Andrey, Ricardo, Martha, Ivo, and Tom for sharing stories.

You can help make this campaign a success. Join the Drupal Association and share your story. How has community connected you with people, resources, and success? Tell your story to the Drupal community members and open source advocates you know.

Spread the word

Personal blog tags: Membershipcommunity cultivation grants

Triquanta Web Solutions: Making your customers pay

Planet Drupal -

A very basic payment set up with webforms and Ogone

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

Go to

/admin/config/services/payment/method/add

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:

  • SHA-1
  • SHA-256
  • SHA-512

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
Best practices

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.

It can happen that the functionality offered by the 'Webform Paymethod Select'-module is not enough for what you want to accomplish but Commerce would still be overkill. So one thing you could do here is use Javascript to create a form that has more possibilities (for example apply discounts according to choices made) and write the result in a read-only number field.

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>]

This way you make sure that any alterations made client-side to the calculated amount are reversed. You should only use the Javascript calculations to provide the customer with feedback, and not use it as the final amount to pay. Not that you don't trust your customers of course...

Been there, done that, still not working

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 page

Conclusion

So now you will have the ability to add simple payments to you webforms. Sometimes however you will notice that, with this in place, your client will be asking for more and more features and suddenly you will find yourself building a complete webshop in custom modules with extra Javascript and extra submit-handlers all over the place. When this happens, be brave enough to confront your customer and negotiate a rebuilt with either commerce (preferable) or ubercart, because very quickly this kind of augmented simple payments will prove to be totally unmaintainable. So, as a rule of thumb: Keep it simple, until keeping it simple makes things too complicated.

Documentation links

Ogone support overview

Ogone guide map

Roy Scholten: Making possible needs examples

Planet Drupal -

Tim blogs about core development being hard. Lee talks about adding sample content. Jeff’s comment there (the first) gives a good example of why core dev is so difficult:

…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

September Drupal Jam and Documentation Sprint

Twin Cities Drupal Group -

Start:  2016-09-21 18:00 - 21:00 America/Chicago Organizers:  Les Lim ivanstegic eojthebrave Event type:  User group meeting

TEN7
718 Washington Ave. N - Suite 301
Minneapolis, MN

YOU are invited to our free-form monthly Drupal-centric or NOT Coder JAM! We get together and make the code - or whatever, in a part-social/part co-working environment.

Documentation sprint

I thought it might be fun to have an impromptu documentation sprint at the September Jam. And if people are interested in participating I'll help to facilitate it. My thought is that we could work together to help with re-organization of content into thew new guides structure. @tvn has been working to the migration of content from one type to another, and for the guides that have been migrated the following tasks need to be done:

  • Locate/recruit a maintainer(s) for each guide
  • Review summary content for each page. Pages now have summaries that are used on listing pages, and many of them could use some love
  • Review content of the guide, identify what's missing, review order that topics are presented in to ensure they make sense

And probably more ... there's a good list here: https://www.drupal.org/drupalorg/docs/content/documentation#first-steps

In particular, I thought it could be fun to choose a guide that we might be interested in maintaing as a group. Then have one or more of us sign-on to do so. Then we could work together with the maintainer to help them resolve any issues they've identified in the content of their guide.

Or something like that. Thoughts?

Background: https://www.drupal.org/drupalorg/blog/documentation-overhaul

Everything else

We ask questions, answer questions, plan events, discuss technology, build DRUPAL websites, have fun!

Held at TEN7! Once everyone arrives, Ivan orders the pizza by popular request. Beverages also provided, and feel free to BYO!

If you need a ride, post a note here and we'll see what we can do. Also post a comment if you are coming!

DrupalCon News: Update on DrupalCon Dublin Program

Planet Drupal -

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. 

Code Enigma: Introducing the Selective Watchdog Backend module

Planet Drupal -

Introducing the Selective Watchdog Backend module Language English Return to Blog Introducing the Selective Watchdog Backend module

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(
    WATCHDOG_CRITICAL,
    WATCHDOG_ERROR,   
  ),
);

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

Drupal core announcements: User Guide 8.x-2.0 released!

Planet Drupal -

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).

Enjoy!

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!

Syntax is Syntax? Lullabot's Non-Drupal Development Work

Lullabot -

Did you know that Lullabot does a significant amount of non-Drupal work? Matt and Mike sit down with several Lullabots who are working on non-Drupal projects including Node, Swift, and React. We talk pros and cons of working in various languages, how they compare to our PHP world, and lots more.

DrupalCon News: Wining and Dining in Dublin

Planet Drupal -

Dublin is a great place to eat out.

You probably won’t be surprised to learn that Dublin has a pretty good selection of bars and restaurants and selecting just a few is a difficult task. This is most certainly not a comprehensive list of venues, but here is a selection of our favourites.

Let us begin with that most important institution: the full Irish breakfast!

September Drupal Happy Hour @ Lake Monster Brewing!

Twin Cities Drupal Group -

Start:  2016-09-08 18:00 - 21:00 America/Chicago Event type:  User group meeting

Join us for our regular Summer Happy Hour location - Lake Monster Brewing! And yes, it's still technically Summer.

Lake Monster has EVERYTHING we need! Just 1505 yards from the Minneapolis Border. TONS of indoor and outdoor seating. Great beer and food truck. Easy location off the Cretin and I94 exit.

Lake Monster Brewing Company
550 Vandalia St #160, St Paul, MN 55114
http://www.lakemonsterbrewing.com/

No computers necessary or even recommended - just social time with maybe a little Drupal talk.

No need to sign up, just show up!

Annertech: How to Get the Most out of DrupalCon Dublin

Planet Drupal -

How to Get the Most out of DrupalCon Dublin

DrupalCon is big. It's got hundreds of sessions. A similar amount of BoFs. Approximately 2,000 attendees. Social events left, right, and centre. It's not hard to get confused, miss things that you promised not to, and leave thinking "damn, I could have done that better". At Annertech, we're Ireland's most seasoned DrupalCon attendees. Here's our guide to making the most of it.

Drop Guard: Meet us in Dublin at booth #105!

Planet Drupal -

Only 20 days are left until we head to Dublin to join the DrupalCon 2016! It’s the first time that we, the Drupal agency team from Bright Solutions (which is the "birthplace" of Drop Guard), arrive at a Con only with our Drop Guard team, so we can focus on our most famous contribution to the Community: our update management service tool “Drop Guard”.

Yes, we’d be happy to show people the great values which Drop Guard provides - but most of all we look forward to personal and honest conversations to progress in our work and as part of the Community!

 

Drupal Drupal Planet Drupalcon

Pages

Subscribe to Cruiskeen Consulting LLC aggregator