Drupal News

Valuebound: How to set the right expectations for project delivery?

  • Setting a clear list of expectation to the client for a project delivery goes a long way to great client relationships. A mismatched and misunderstood project goal and target always leads to dissatisfaction among team members, account head, and all other stakeholders.

    I manage a team of a few developers who build web applications in Drupal. While working on projects with my team, I have had the chance to practice a few of the points that I have mentioned in the article. It has not only kept us on track but also kept people happy and motivated.

    What should you do? Be involved from the beginning

    When you begin a project makes sure that you and your team members are involved in the project from the beginning. There are times when the team would expand…

    3 days 9 hours ago

MD Systems blog: Using Commerce for a newspaper subscription shop

Appnovation Technologies: The Future of Drupal

  • The Future of Drupal *Cross-posted from Millwood Online.  Over the past month there has been a lot of focus on Drupal, the community. More recently it seems people are back to thinking about the software. Dave Hall and David Hernandez both posted eye opening posts with thoughts and ideas of what needs doing and how we can more forward. A one line summary of those posts would be "...

    3 days 9 hours ago

Third party settings in custom entity fields

Weekly Drupal beginner questions thread

Code Positive: Rich Snippets & Structured data

Which versions of Drupal 7 & php 7 to use

Acquia Lightning Blog: Experimental module warnings and Lightning

  • Experimental module warnings and Lightning Adam Balsam Sat, 05/20/2017 - 20:28

    Lightning has used the Layout Plugin module since before our first beta release. Starting in Drupal 8.3.0, the functionality provided by the Layout Plugin module was largely duplicated in Layout Discovery and released as part of the Core Experimental group. Lightning migrated to Layout Discovery in 2.1.1.

    The Lightning team feels like it's a win anytime we can migrate from contrib to core. But another advantage of this is that since Layout Discovery is in Core, security issues can be filed against it in the Core security issue queue which is monitored by the Security Team. Layout Plugin, being alpha, didn't have a security issue queue.

    Technically, Layout Discovery is an Experimental core module though. And the new Status Report page warns users if any Experimental modules are enabled. As a result users of Lightning are presented with this unhelpful message when they visit /admin/reports/status:


    The problem is, this message isn't actionable. Lightning made the decision to enable it. The only way to disable it would be to completely opt out of all of Lightning's Layout functionality.

    To be clear, the Lightning team feels that the Layout Discovery module is certainly stable enough to run predictably and reliably on production websites. This warning from core is supposed to indicate that the underlying API might change or that it might ultimately be removed from the core package. Under either of those circumstances, Lightning would provide a migration script or otherwise support users.

    We feel that warning a user after they (or their site builder) has made the decision to use an experimental module is in-actionable nagging. We support warning site builders when installing an experimental module, but not constantly reminding them of that decision.

    Starting in 2.1.4, Lightning will include a core patch that removes the warnings for experimental modules on the status page. The patch does not affect the existing warning that is shown during installation of experimental modules.

    There are two other "nagging" warnings that Lightning will remove in 2.1.4. Specifically, it will stop warning the user if:

    Related, there is also a larger discussion around what the requirements should be for reporting on the status page. Discuss!

    Summary of new patches related to reporting that will be included in 2.1.4:
    • Remove scary 'experimental module' messages from appearing everywhere on the site (#2880374)
    • Config sync should not throw a warning when not being writable (#2880445)
    • Disable warning about update notifications (#2869592)

    5 days 1 hour ago

Session variables or passing variables in a Drupal module?

  • I'm quite new to Drupal development and could use a little clarification (please):

    I need to pass an object to a function within a custom module. This function is only ever called from one place. Should I pass it as a parameter to the function or should I store it on the session then retrieve it from inside the function? (Does it matter?)

    Most of the data I need is already on the session from elsewhere so it seems almost pointless to retrieve it then pass it to the function.


    function function1() { function2($_SESSION['value1'], $otherVar); } function function2($var1, $var2) { //do stuff }


    function function1() { function2($otherVar); } function function2($var2) { $var1 = $_SESSION['value1']; //do stuff } submitted by /u/erm_what_
    [link] [comments]

    5 days 10 hours ago