What are /r/drupal's favorite Products & Services?

From 3.5 billion Reddit comments

So, to be affected by this you'd have to:

• Be using a compromised internet connection (MITMed)
• Be logged into an administrative account on a Drupal site
• Update your modules through the admin UI (which is not the case for those using version control, drush, etc.)
• Not be using a hosting platform like Pantheon, Platform.sh, Acquia Cloud, etc.
• See an update, click the button to update the module without checking the module info by clicking the download link or readme, etc.

If all of the above is true, an attacker could gain access to your site.

Yes, it's plausible, and yes, we should at least switch Drupal core to use https and make sure certs are checked when pulling update XML, but no, it's nowhere near (not even in the same league as) Drupageddon.

See also: https://www.drupal.org/node/1538118

Your guess is as good as mine, the DA board is about as transparent as a concrete wall. They don't even publish the meeting minutes any more.

Since mortendk was kicked off the board (with some silly pretense), I haven't heard of anyone calling Dries and the other executives on their bullshit. You could get the impression that the board mostly serves as a big rubber stamp that only serves to make DA leadership feel a bit more democratic and open.

Just recently, chx... and now Crell... Where does it stop, Dries?

There is a pathological witchhunt roaming drupal's corridors - apparently OK, as we don't - and probably won't see - the privacy intruding witchhunters, ousted.

Drupal went far beyond enterprise and into corporate, privacy invading conspiracies - all too well presented in nicely finessed corporate lingo - well done.

Morbus Iff went bazooka with dignity https://www.drupal.org/node/2863181 and a few other ladies and gents said their piece, here and on other sites.

This act by the drupal powers wont bode positively with the PHP and Symfony communities — the undesired side-effect.

This shit-storm will hit the fan, big time, in hard to anticipate ways.

Literal groans in the office when this started going around.

I'm not mad about it, and really appreciate the forewarning from the security so I can make a hole in my time for this. They (or we, if you're contrib-minded) really gotta work on getting auto security updates in place though https://www.drupal.org/project/drupal/issues/2367319 . Or at least come up with some better management tooling.

Instead of messing with yaml directly you can use https://www.drupal.org/project/restui and capture the config of it, way easier.

Also check your permissions under People -> Permissions, ensure that the user has permissions for the endpoint you're trying to use.

And last, be sure to visit /session/token to fetch a token for the call. When you do a POST you'll for sure need to set HTTP header X-Csrf-Token to the token value for it to work.

It is kind of a pain, but isn't pretty much anything that involves users / permissions like that?

Drupal isn't fading away it's just becoming an enterprise CMS. As a reflection of that usually the best place to get support these days is the Drupal slack channel: https://www.drupal.org/slack

I mean, Drupal is just Symfony at this point. It provides a framework of helpful classes and functions that reduces redundancy when developing webapps. I say webapps because very few organizations actually use Drupal on the front end, instead they lean on Drupal providing the JSON or components that can be pushed out to Android, iOs, or web applications.

Outside of tooling your own framework, Drupal is still probably the best and most flexible CMS for publishers with large amounts of different types content.

edit: wrong link.

~~While the security risk score is slightly lower than last time,~~ everybody should upgrade their Drupal sites ASAP. The security risk now has been bumped up to Highly Critical.

Update: If you are using the Media module, update that as well: https://www.drupal.org/sa-contrib-2018-020

While backdrop the code can be seen as a fork of drupal 7, what it definitely is not is a fork of the community and all that goes along with it.

1. Backdrop has 2 main contributors, and maybe 20-25 additional people helping out porting modules and submitting random pull request. There is very little evidence that their reason for forking had much traction or resonance from the community.
2. Drupal 8 had 1583 different people submit 32851 patches in 2014. 758 of those people are new contributors in 2014.
3. Drupal provides an updates service to let you know when your code is out of date, backdrop you'll need to check github.
4. Drupal has a security team with many extremely competent volunteers on it. "Backdrop CMS does not yet have any security announcements." (From here https://backdropcms.org/security)
5. It lacks a command line tool like drush that would facilitate management.
6. A website isnt something you buy once and just have. It is going to constantly grow and change, and if you're a small business owner you're going to need to find people who can manage your site and your needs. It will be difficult to find people who advertise themselves as backdrop experts once it diverges far enough from drupal 7 that they're truly different products. Its hard enough as it is to find a drupal developer who isnt already working for an agency building big projects.

In all, while I feel like its a noble effort, I think the developers have grossly underestimated the herculean task they have taken on, and without a massive influx of people to help them, they are going to basically be trying to catch up to the functionality that drupal 7 provides, without actually surpassing any of its functionality, and yet be unable to produce a product that can compete with something like wordpress.

Looking at the usage graph:

https://www.drupal.org/project/usage/drupal

Drupal 8 has been a pretty monumental failure in terms of usage, when they EOL Drupal 7 in 2021, unless they can turn things around and make Drupal 9 appealing in a way that 8 isn't. I don't fancy their chances.

It feels like the direction Drupal is going in is designed soley to keep Acquia ticking over with big enterprise clients, as a smaller site-builder I'm no longer recommending Drupal, which is a shame as i have 6 years of experience with it in various forms that i don't really want to lose, but so little of that is transferable to D8 it's just as easy to switch something else as it would be to learn D8/9.

Add to this the Drupal orgs rather poor handling of various things, such as the weird trademark situation which benefits Dries more than the community, their cancelling of the official europe con, downsizing of drupal org itself by firing some long time staffers, the critial security updates that are always at stupid o'clock for europeans...

> We received one side of the story, from one perspective

We've also heard from the DA, CWG, and Dries.

 

> At the same time, though, I feel we have a wall for a reason.

I'm not as faithful in the decision making process.

 

> I didn't see a ban hammer which removed him from Drupal.org.. just some of the leadership

No, Dries removed him from the community. From Dries' blog post, " I made the decision to ask Larry not to participate in the Drupal project"

 

> why is everyone so hung up on Dries and the DA?

It's not the DA, it's that Dries controls the DA. He is the president, and has the authority to tell Megan exactly what to do.

 

> If we feel we are the community and own it, then do so.

The DA (and therefore Dries) control Drupal.org and Drupalcon. We cannot own it without that unless we fork the project (which is a horrible idea IMO).

The overall number of Drupal sites has been flat since 2015. It's the turquoise line on that graph.

Drupal 8 installs are rising slowly but at the expense of D7 and D6. So people are ~~upgrading~~ migrating their Drupal sites to the latest version but few completely new Drupal sites are being built.

The writing is on the wall. Drupal has peaked. Learn JS if you can stand it. Other interesting options include Laravel, Python or backdrop (a D7 fork that I tried out yesterday. It's pretty great!)

We recently launched our first D8 Webshop using Commerce 2. It took a little while to get used to the Commerce 2, but in the end we're really happy, we chose D8 instead of 7. Just today we started working on the next Shop using D8 Commerce 2.

If we'd known the D7 EOL when the decision for D8 was made, we would probably have chosen D7. Even tho none of the really important modules is missing, many payment providers are not supplying a Drupal 8 version of their payment modules yet, which is the only drawback I can see.

But in the end we figured, if our client really wants to use a payment provider that does not supply a D8 module, we'd at least have a good reason to write our own payment module and would probably also get funding for it.

Edit: Whenever I posted problems in the Commerce 2 issue queue on drupal.org, I got a useful answer within a few days. Some guys over there, especially bojanz, are really doing a great job, answering questions and helping out with problems.

Probably the migrate module.

You should seriously consider going straight from D6 to D8 as the migration will be about the same difficulty, unless you have lots of custom modules.

If you're going to have custom content types that are likely to be used in different sites I'd recommend creating a custom module that contains the yml files for the content types. You can do the same with views, view modes, menus, roles, etc.

If you think there will be a lot of overlap in functionality and configuration, you may want to make a profile to store your custom/contrib modules and themes.

Was discussing some custom functionality that I had on my site with someone else in the community and decided to attempt open sourcing it and after a couple late nights released the initial version yesterday! It allows site administrators to set fields to required on publish and, internally, has allowed our editors to be able to focus on content creation first and then proper tagging or SEO information right before the content is ready to be published. I'm sure there are edge cases that I haven't tested yet but hopefully someone finds it useful!

https://www.drupal.org/project/require_on_publish

I've been brought in to cleaned a few sites now from this, hate to say it, but you're going to need to do more. The scripted attacks get deeper than just file drops, they open up admin access to the system, so you'll need to clean beyond what you've done.

The process I've been using:

• Take the site offline
• Empty all your caches, both file and database caches.
  
• Create a new directory for your site
• Download a clean copy of Drupal, all contrib modules and your base theme.
  
• Do a deep review of anything executable in your theme and files directory to validate everything is clean before you copy to the new directory. Worth running it through an AV scanner, and grep -r -n -i 'eval()' at minimum.
• Make sure the .htaccess has been restored in the files directory.
• Typically this malware is creating a new admin user or two, and a new oddly named role that has admin permissions.
  
• Look for any users and roles created since the hack, remove them.
• Change database password in settings.php, drupal admin password, hosting account password.
• Check the input format filters and formats assigned to content types and comments.
• If your site allows users to login, bulk reset everyone's passwords - run this from a SQL shell update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))));

Finally - if the site allowed people to log in, or stored sensitive data. Notify your users of a complete breach.

Official Drupal docs on handling this, with lots more details and suggestions are here: https://www.drupal.org/node/2365547

> The only people claiming that this has anything whatsoever to do with Larry's kink are Larry himself and his defenders.

That's preposterous. If you've seen any of the material being passed around to smear Larry, you'll notice it's all related to Gor, and in their latest statement, the DA refer to “information from one or more members-only sites”, which pretty much confirms what Larry was saying about the closed forum frequented by Goreans.

> It looks like a self-important obsession - totally immature and delusional.

Ah, insults, always the weapon of choice of someone who's lost the argument.

Can we please cut down on the Drupal 8 hype? Half the posts on this sub-reddit are pushing the benefits of software that won't be usable for most people until 2016.

We've been hyping and discussing Drupal since 2010 now: https://www.drupal.org/node/963832

"But now, in 2010, there is a lot of momentum behind using HTML5. Shall we switch to HTML5 in Drupal 8?"

"if Drupal 8 is going to be released before 2013..."

Your guy needs to Level up. D6 is basically obsolete

"On February 24th 2016, Drupal 6 will reach end of life and no longer be supported."

See: Automatic Updates initiative. It’s a pretty big issue, highlighted by Dries in two DrupalCon keynotes now, and the community has been working on finding the best way forward. Unfortunately, for a CMS like Drupal, this is not an easy or simple problem to solve, at least if we want to do it in a more secure way than what Wordpress currently does.

Drupal lists service providers for different locations or specialities: https://www.drupal.org/drupal-services

They're ranked by factors including how many Drupal modules they support and how many issues their employees helped resolve for Drupal core or contributed modules in the last 90 days.

Statement from the Drupal Association Executive Director saying she made the final decision: https://www.drupal.org/association/blog/a-statement-from-the-executive-director

Statement from the CWG which confirms that they found no Code of Conduct violation, but "some of the issues raised were outside the scope of its charter and it was appropriate for the matter to be escalated to Dries" https://docs.google.com/document/d/1tcwuuip9qAMtGNir7_aD1zhWubEkisNnkG3n7CHFPbM/edit

Statement from the Drupal Association Executive Director saying she made the final decision: https://www.drupal.org/association/blog/a-statement-from-the-executive-director

Statement from the CWG which confirms that they found no Code of Conduct violation, but "some of the issues raised were outside the scope of its charter and that it was appropriate for the matter to be escalated to Dries": https://docs.google.com/document/d/1tcwuuip9qAMtGNir7_aD1zhWubEkisNnkG3n7CHFPbM/edit

The terminology can be very confusing, particularly in meetings with non-drupalers, because people use the word template so loosely that it covers pretty much anything. But, in Drupal, a "Theme" is a collection of templates, css, javascript, images, etc. If you look at what a theme is composed of, you'll notice that there are templates embedded in templates, an inception of templates. Almost every object in Drupal has a template file that can be overridden or modified to meet the requirements of your markup. This help page gives a pretty good example of the structure. It's for D7, but the idea still holds in d8. https://www.drupal.org/docs/7/theming/overview-of-theme-files

Zen is a decent "blank" theme to start with https://www.drupal.org/project/zen that doesn't require tons of CSS overrides to get the site into the shape you want.

What you want to do is to override zen in a custom sub-theme https://www.drupal.org/node/225125

In your info file for your custom theme you will add your own CSS and JS files (paths relative to the .info file).

If you want to change the basic HTML of something, make a directory in your theme called "templates" and then copy existing templates from zen/templates into your own custom templates dir and hack away.

Whatever you do, don't hack existing Drupal themes or modules, figure out some way to override!

Edit: oh and forgot to mention. If you add and or remove templates, or you read about some trick to put inside yourtheme/template.php, flush the cache afterwards. If your changes ever don't look like they got applied immediately, go to Configuration -> Development -> Performance and hit the clear cache button.

Only give them access to what they need to maintain their site. Provide them with a regular, day-to-day login with access to nothing more that what they need. As the site owner, also supply them with the admin account - but this should not be for regular use - only in case they switch developers or you get hit by a bus.

I typically create Content Admin, Site Admin and Store Admin (for ecommerce) roles. Content admins can create and edit site content . Site Admins can view reports, create users, etc.

I never give the regular user account access to Views admin. There is a great module View UI Basic Settings that allows you to configure the site so a user can edit a View's header and footer without having to give them full access.

TIP: Make sure all of your Admin roles have access to "View Administration Theme".

Facets https://www.drupal.org/project/facets

Honestly, for me anyway, modules such as custom breadcrumbs and Rules etc. always seem heavy handed when it's really easy to write your own custom breadcrumb that is specific to what you're building. hook_preprocess_breadcrumbs is often all you would need.

Of course if you're more of a site builder than developer, I guess this doesn't help.

Same with Rules. It's a highly complex module that provides far more than what you probably need and can usually write in a custom module in far fewer lines of code.

Anyway, that's my thoughts on such modules!

Check out the contrib module scheduler: https://www.drupal.org/project/scheduler

Allows you to schedule the publishing (or unpublishing) a post at a specific date/time. Works great. As I recall, you just install the module then edit the content type you want to be able to schedule to allow it. Finally, when you actually create a post, you can set the schedule time in the add/edit form.

You probably want to integrate with an ad server. The buyers are going to have more and more requests, reporting requirements, etc. Drupal isn't the best place to manage all that.

Sign up for a free Google Doubleclick For Publishers account, then use the Drupal DFP module to create placable blocks for your ad units.

Once you set up the ad units on your pages, create a campaign in DFP by creating a "New Order" and limit the impressions to 50,000. You can then say "Only one" under "Display creatives" to limit the campaign to only show one ad per page.

I realize this isn't an easy path, but the up-front work you put into this will pay dividends in the long term if you're really going to be selling ads.

I know this may be nothing to many but as a site builder that can't write a single line if php, get to know the Rules module. You can pretty much do anything with it. I know hardcore devs may scoff as it is not as performant and would prefer to roll their own custom code. But creating custom workflows or actions with rules means no custom code to keep on top of and you can have more control over your site. Rules might seem overwhelming at first but stick with it. Combine it with Rules scheduler, flag and VBO and you can do some pretty nifty backend admin features for your clients as well. See the learn rules video series from nodeone/wunderkrout. I would link to it but it appears that their site is down at this time.

https://www.drupal.org/project/rules

In Drupal 7.33+, if I'm wrangling template suggestions, this is like replacing a candle with a floodlight when fumbling around in a dark room...

$conf['theme_debug'] = true;

theme_debug

Like /u/ganjamensch said, contrib modules often don't have the best documentation. People who do work on contrib modules often do it for fun in their spare time, and writing documentation isn't fun, so it's tougher to get people to do it when they aren't getting paid for it.

The good thing is that people like you and me have the ability to improve that. Figure out what you need by digging through the code and asking questions on http://drupal.stackexchange.com or in IRC, and then add a new child page to https://www.drupal.org/documentation/modules/path-redirect with the information that you find, so the next person doesn't have to do the same thing that you did.

You Need to build your own module! Once you get the hang of it, it would take you about 15 minutes to integrate already existing code, but I recommend understanding the module and hook system first. https://www.drupal.org/developing/modules

Download and enable admin_menu module. If you are using drush, just type:

drush pm-download -y admin_menu drush pm-enable -y admin_menu

edit: formating

Baaaaaaaaaaaaaaaaaaaaaaait. But fine, I'll bite.

You might be interested in the CMS Kickstart distro. It's a fairly new one that seems to be ambitiously trying to make Drupal 7 as WordPress-ish as possible. And yes, as others have said, D8 will have further UX improvements for "normal people," though most of the improvements are just bringing into core things that were developed in the D7 contrib space.

That being said, you seem to have a fixation on WYSIWYG editors (and you're not alone on this). Let me tell you, on ever D8 site I build, I'm going to be disabling that bullsheezy (or, more precisely, not enabling it in the first place, since I never use the standard install profile anymore). Using WYSIWYG is the wrong solution for almost every use case, and is the quickest way to get sites with purple italicized and underlined 36-point Times New Roman text on a site that otherwise uses Verdana. And then you want to give them the ability to upload arbitrary files to the editor too?

Yes, ugliness can be reduced by locking down what people can do with the editor, but it's still better to just give them a separate header image field or a separate subtitle field or whatever and enforce consistency that way. If they must have inline links or titles, then they can learn Markdown or HTML, or use BUEditor if they refuse to.

I fight clients that want a WYSIWYG editor, because it's usually in their best interest to not have one. And usually, after explaining how we can achieve the desired effect with proper fields and theming, I can win.

You should never be able to see a users passwords, this is a huge security no go. Quick google result about the basics: https://thisinterestsme.com/secure-passwords-with-php/

You are looking for a way to impersonate a user, you can try this module: https://www.drupal.org/project/masquerade

I just updated a couple of D7 and D8 sites. Everything worked fine, no problems so far.

D8 sites were updated using composer (drupal-composer/drupal-project template), D7 sites updated with drush.

When you're using rabbit_hole, make sure to upgrade to drupal/rabbit_hole 1.0.0-beta6 or you'll get a WSOD.

The Entity Links translation bug is still not fixed in 8.7.1. Patch #88 from the issue queue is still working well, even though automatic tests failed on it. But there are also some newer patches addressing 8.7.x. and 8.8.x.

Most of the above mention webform related modules are no longer needed.

@see What Drupal 7 Webform related projects have been incorporated into the Webform module for Drupal 8

​

> With 8 and 7 having the same end of life date, I would think twice about the benefits of the upgrade.

One of the primary goals for the upgrade from 8 -> 9 is for it to have a minimal impact. It does not look like they will be attempting to add major features but mostly just addressing the symphony 3 EoL:

https://www.drupal.org/project/drupal/issues/2608496

> The Drupal 8 to Drupal 9 upgrade path is expected to be similar to an upgrade path between minor Drupal 8 releases, because we will only drop backwards compatibility layers, not make new significant API breaks in 9.0.0.

I'm afraid I'll have to pull that dreaded "let me not answer your question and instead tell you it is the wrong question" response here.

If you need significantly different markup then rather than have one template with an if/else check of the content-type in, you can create another template node__content-type.tpl.php which via theme hook suggestions will automatically be used instead of the generic node.tpl.php.

Ideally the container/wrapper would in both cases be in this node level tpl but if it has to be in the page.tpl you can force a content-type-based variant theme hook at the page level too - ctrl+f for "Add a page.tpl.php depending on content type" on that theme hook suggestions link.

If you are only needed to change a class or two then you might be ok with just one template. Still, you will want to avoid direct checking of content types and if/else branches in your tpl as much as possible. You can use a preprocess hook to change the classes at the render array stage.

I've used Owl Carousel on one website years ago. It was alright, but if I update the module everything breaks.

I've been using Slick Carousel for the last couple years and I really like it:

https://www.drupal.org/project/slick

http://kenwheeler.github.io/slick/

The upgrade wasn't simply to fix a bug, there was a major security problem. More info here: https://www.drupal.org/sa-core-2018-004

But from the sounds of it, the site has been compromised. Best bet is to restore from a backup from before the vulnerability was announced.

It is just a refresh of the calculation of the security risk: https://www.drupal.org/drupal-security-team/security-risk-levels-defined

Now that that it is no longer theoretically but bots searching for vulnerable sites, the score gets higher.

Very first paragraph of the Release Notes:

>Versions of Drush earlier than 8.1.12 will not work with Drupal 8.4.x. Update Drush to 8.1.12 or higher before using it to update to Drupal core 8.4.x or you will encounter fatal errors that prevent updates from running.

Sure! This can be done fairly easily.

I recommend getting the Conditional Rules Module to help with this.

1.) Create a new View that displays content of the "Events" type. (Does not need a Page or Block. Can be done within the Master view.)

2.) By default, the View will likely only show about 10 results per page. Change this to display all items

3.) Add a "Bulk Operations: Content" field

4.) Create a new Rule and have it activate on a Drupal Cron Job (Or you can use the Scheduler or Rules Once per Day if every Cron Job is too often)

5.) Create an Action to Load a List of Entity Objects from a VBO View and then select the View you created in Step 1. (Let's say that you name the list "event_list")

6.) Create a Loop and select "event-list". (Let's say that you name each item "current_event")

7.) Within the loop, add a "Conditional"

8.) Within the Conditional, add an "If" for if "Content is of Type" and then select "Event" (This gives us access to the Date field you are using)

9.) Within the Conditional, add an "If" for Data Comparison

10.) Under Data to Compare, select the date field's end date

11.) Under Data value, be sure you are in Direct Input mode and type "30 days ago" Note: If you need more info, check out PHP Relative time.

12.) Within that Conditional, add an Action

13.) Select "Unpublish Content" and for the node, select "current-event"

14.) After that, you should be done! Run the Drupal Cron and the old Event nodes should be unpublished.

Pretty much what it is doing is this: - On every Cron Run, Rules grabs every Event node via VBO - Rules checks to see if any Event Nodes ended 30 days ago - If an Event Node has its end date end 30 days ago, it is unpublished.

Please let me know if you have any questions!

> the Code of Conduct which establishes the values

The DCoC does not establish values. it does establish how to treat others.

Read it for yourself at https://www.drupal.org/dcoc. It's pretty short.

No, but frankly, if Ubercart and Drupal Commerce are too complex for the people who talk to you, they might as well just run a lemonade stand on the sidewalk -- other ecommerce platforms are just as complex, if not more so.

If you are setting up Drupal Commerce, be sure to install the Commerce Backoffice module (https://www.drupal.org/project/commerce_backoffice) -- it simplifies some of the more unorthodox DC administration stuff and makes it less difficult to use.

This is a very generic question. It sounds like you need to read up on Drupal theming in general. There could be several ways to do what you want, but cannot recommend a solution with such an open-ended question.

Drupal Theming Documentation

Omega 4 has indeed changed radically since Omega 3. From the Omega project page:

>Omega 4.x is a base theme framework aimed at themers who want to gain full control over the theme through code, rather than a user interface. If you depend on the user interface you can continue using Omega 3.x.

And from the Omega 4 docs:

>Do you rely on the user interface for building layouts, or are you comfortable defining layouts in code in a tpl.php file? Omega 4.x does not include the elaborate layout definition UI that was a hallmark of Omega 3.x

Other's have mentioned groups which would help you do the subreddits. There's other useful bits:

• https://www.drupal.org/project/vote_up_down for voting

• https://www.drupal.org/project/radioactivity - if you sorted by raw number of votes then very popular posts would stick at the top of lists forever. this module has a score value you can customize that decays over time so if you sort by this instead of raw votes eventually newer stuff overtakes popular older stuff.

There's a module for that! The Rabbit Hole module allows you to prevent access to hitting nodes directly, and what you'd like to do instead (redirect, page not found, etc).

First of all, ALWAYS BACKUP! No matter if it's WordPress, Drupal or any other system you are updating.

Second, if the version difference isn't too large, eg. upgrading from 7.52, you should be fine. However, all versions before 7.59 have a big security bug (https://www.drupal.org/sa-core-2018-004). So chances are that site has been hacked ... You'll need to clean your site first if that's the case.

> What do you like and/or dislike about Drupal? > What are Drupal's strengths and weaknesses?

I liked the Drupal's flexibility - it is also a strength. Drupal is not just a CMS, it is also a framework. You can use Drupal to create a simple personal blog site, to an enterprise application.

I liked the architecture and environment (PHP environment considered here) shift in Drupal 8 from Drupal 7. Drupal 8 is now more aligned to the modern PHP frameworks. You can easily use a third-party Composer package in 8, which was hard (and not built-in) in 7.

The ease of managing site configurations is much smoother and easy in 8. Compared to 7 - using features module.

Drupal has a steep learning curve. I would not say that is a weakness, but it is a challenge and a blocker for newcomers. While working in Drupal 8 I also felt that the documentations/tutorials need improvement, and you might have to dig into the module code to do some custom work. Community has already taken initiatives 1, 2 to improve the docs. +1 on that.

> How does it compare with other CMS platforms you have used in the past?

I worked on Wordpress for a short term. I found Drupal more sophisticated than Wordpress - considering the code and architecture. This was ~4 years back, I don't know the current state of Wordpress.

> What is your overall development experience?

8/10

+1 for the friendly Drupal community.

You'd probably be interested in reading @lauriii's response here: https://www.drupal.org/project/ideas/issues/2913628#comment-12289381

You can subscribe to alerts directly from the security team. From the PSA

he announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: login on Drupal.org, go to your user profile page, and subscribe to the security newsletter on the Edit » My newsletters tab.

First of all, if you are running Drupal 7.56 instead of Drupal 7.58 you probably want to run, not walk, over to SA-CORE-2018-002 because we've been seeing live attacks that work on Drupal <7.58 since April 13 (on our sites). You might want to grep for element_parents in your webserver logs.

Drupal core already has facility for doing what you want with block caching.

If you go to Administration / Configuration / Performance you will see several caching controls. You should check "Cache blocks" if you want blocks to be cached. If you are running MySQL/MariaDB as your backend that means that cached blocks will be stored in the cache_block table the first time an anonymous user sees them, and they will be quickly served from here instead of rebuilt on each subsequent anonymous request. A real performance boost.

Also on the Performance page you will see something called "Minimum cache lifetime". If you have this set to None it means that if you were to add a page, when you click the Save button block caches will be cleared. A minimum cache lifetime of None says to Drupal, "when there is new content created please clear the block cache immediately".

If you were to set the Minimum cache lifetime to 1 min, the block caches would be recreated on the first anonymous request that occurs more than one minute after you have created your new content.

There is no reason to do a massive cache clear on everything in order to clear the block cache.

If you do have a more complicated site where you have custom modules messing around with caches you can always implement a hook to clear the block cache only with cache_clear_all('*', 'cache_block', TRUE).

It appears to be a patch for part of the Drupal CMS that checks for the strength of a password: https://www.drupal.org/project/drupal/issues/1497290

Not sure what your father has anything to do with it, but perhaps his name is a common word?

Webform for Drupal 8 is still in beta because it is a completely new code base.

> Even though the Webform module is still under active development with regular beta releases, all existing configuration, and submission data will be maintained and updated between releases. APIs can and will be changing while this module moves from beta releases to a final release candidate. > > Simply put, if you install and use the Webform module out of the box AS-IS, you should be okay. Once you start extending webforms with plugins, altering hooks, and overriding templates, you will need to read each release's notes and assume that things will be changing. > From: https://www.drupal.org/node/2834423

The most ironic thing might be your client ran into this issue about Remote post error handling which could cause leads to be silently lost.

Enterprise clients like pharmaceuticals need to get more involved in the Open Source community.

Still, I agree with the overall sentiment that the contrib modules (including Webform) for Drupal 8 is going through some growing/support pains. We all need to collaborate and fix these problems.

> I disagree. Part of Drupal 7's best utility was that once it was set up properly, code rarely needed to be deployed.

Honestly, and I blame acquia and community leaders for this, that ship has sailed. Drupal 8 is probably the most complex CMS I've ever used.

Yes it's very powerful for content admins, and even 'power admins' who get into things like views. But the simple coding/setup is gone. I'd never recommend D8 to an individual without a php dev on staff or on retainer.

I think that decision was made a long time ago (for good reasons) but the conversation about it wasn't honest. Yes people who use the gui will be fine but those that want to poke and prod and do simple tweaks? Sorry, not the product for you anymore. I don't mean this in a mean way at all, I just think it's the reality. Your seeing it with the move away from feeds to migration. A developer first tool.

edit: for what it's worth after looking at the https://www.drupal.org/project/migrate_source_csv page and reading the link showing how to set up a csv migration, I'm doubling down on this opinion. If you can't complete some due diligence and read the article showing literally a 40 line yml file and basically spelling it out for them, they are not going to appreciate drupal 8. https://www.mtech-llc.com/blog/lucas-hedding/migrating-using-csv

> it is important to note that this has been a careful, and deliberate process that has been going on since October 2016

https://www.drupal.org/association/blog/working-through-the-concerns-of-our-community?page=3#comment-12024740

What about Jimmy Berry? https://www.drupal.org/u/boombatower

> As a long time Drupal developer who was heavily involved and was also forced out by SJW culture and backstabbing I can attest to this being bogus. Chx simply had a higher resistance than the rest of us and overcame their bs multiple times (see his blog posts about quitting Drupal core...multiple times). Technical merit holds no sway over there and barely did years ago. They broke their own rules about project ownership to steal mine and that same working group did nothing about it after spending lots of time communicating with them. All so they could utilize an utterly inferior solution by all technical accounts. The only difference was the new leader was a fellow SJW, while I am not... [...]

https://www.reddit.com/r/PHP/comments/5eaklo/karoly_n%C3%A9gyesi_chx_ousted_from_the_drupal/dab3uhx/

Drupal is a CMS that you have to build, see it as a Lego compared to the already-built Wordpress that is hard to change.

Depending on the skill of your PHP devs, you might want to start with Drupal 7. The modules are more mature and the learning curve is less steep than Drupal 8.

Drupal 8 has features that will be very useful in the future. Front-end editing, GraphQL, try it here: https://www.drupal.org/try-drupal

So if you want to do it fast and cheap, go get a theme (like https://themeforest.net/item/maxblog-flat-news-magazine-blog-drupal/12217684?s_rank=6 ), install it and see what you can do with Drupal 7.

If you want a future-proof backend that will also power your Mobile app, Facebook pages, etc., invest in D8.

If you are experiencing issues with cached content not updating regularly enough, you can use the Cache Expiration module to configure this.

This will allow to define rules that expire cached pages, e.g., you could define a rule to expire the homepage, blog view and relevant blog node's cached page every time a blog node is updated.

This is a much better solution than allowing non-technical users to flush caches - this should typically be reserved for admins. With a correctly configured cache expiration system you should only need to flush the cache in production when the codebase is updated.

Just learned about Forena Reports.

Views was just much too slow working with relational data. While I'm more than happy to put together some dynamic queries to generate data, Forena had a whole mess of great features right out of the box like outputting to different formats and theming.

It's not the simplest module to use, but as someone with a good background in SSRS Forena's model made a lot of sense.

https://www.drupal.org/project/advagg/ can do this and more; the most useful in terms of actual performance improvements is deferring the javascript.

View the source of https://www.drupal.org/ to see it in action.

While it isn't a new module, it isn't used by a tremendous number of users; https://www.drupal.org/project/advagg is a very impressive CSS/Javascript aggregator that has really helped with our Google Pagespeed scores.

Similarly not new, https://www.drupal.org/project/boost has been an absolutely life saver for our non-interactive sites, allowing us to cram millions (yes, millions) of visits in a very short period of time on a very small server footprint.

I believe React itself has been relicensed. However, there was some debate on HN about GraphQL, etc., but the debate didn't amount to much.

You sound like a good candidate for https://backdropcms.org, which is an awesome free open source fork of Drupal 7, that has a lot of Drupal 8 features such as config management, etc. It does not have Symfony or Composer dependencies.

You're doing it the right way.

Hacking core refers to making changes to anything outside of the "sites"-folder. In general, the sites-folder is where all non-core stuff (themes, modules, custom code, uploaded files, ...) should reside.

Regarding overriding templates, https://www.drupal.org/node/173880 should get you all the info you need.

Actually you should not hack Zen. You can extend it. https://www.drupal.org/node/1010576

Your extended Zen theme will have just a couple files. An .info file with some stuff in it, notably the info telling it to extend Zen and a stylesheets[all][] = site.css Then just fill up site.css! Paths in it will be relative to the theme directory, so you can have a css/ or images/ dir inside to keep things organized. HTH!

Edit: oh in case I wasn't being super clear. Drupal helps you override Zen and have your own theme files (this avoids breaking updates - if a security issue was found in Zen all you have to do now is replace Zen entirely, not tiptoe through it putting your changes into a new Zen version). But the CSS that already exists in Zen, though minimal, also needs to be overridden... e.g. a Zen CSS rule already exists that you want to change. In this case use CSS specificity for overrides. Often just copy the selector of the Zen or Drupal core CSS rule and put like BODY in front. Or #content. Etc. Make it more specific so browser uses your rule instead of the ones in Zen or core.

It takes much more than a week to create a Drupal solution that isn't a complete disaster and a total disservice to your customer. That said Drupal theming by itself isn't overly difficult, the very first thing you need to understand is how to properly extend a base theme.

Step 1: Pick a base theme that is somewhat close to what you want: https://www.drupal.org/node/323993

Step 2: After you copy the base theme into sites/all/themes you need to create a sub theme based on it and activate that subtheme in Drupal: https://www.drupal.org/node/1010576

Now it is mostly a matter of finding the templates in the base theme you want to modify and copying them into your subtheme then modifying them. This isn't too bad, then you realize if you want to do anything beyond the most rudimentary blog layout you will need to install one or more of the following modules: views, panels or display suite. Then you end up basically diverging from the default templating system, my current project has Drupal templates, views templates and DS templates and none of these template systems have a whole lot in common.

edit - oh yeah all the raw data you wish you could deal with is buried at least 3 levels deep in a piece of crap multi dimensional associative array. Some of that "data" will have already been somewhat marked up by Drupal and in need of a strip tags + reformat to decrapify it.

1) Most people will advise from issuing too many commands while logged into root. The correct way is to create a user with sudo rights and disable root SSH login all together. Then add the user to the same groups as the Apache/PHP-FPM process and apply the chmod permission of "775".

2) It's a massive undertaking to try and disguise Drupal. What exactly are you trying to solve by masking Drupal? Security?

3) Certbot can be issued in "bundles". Call for certs that make sense - AKA all of the same domains issued at the same time. https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-18-04

I don't recall whether there's a built in way to do this, but I always found that option kind of crappy by default. I'd take a look at https://www.drupal.org/project/smart_trim and see if that does what you need

Like I mentioned in the other comment, twitter is not a support channel. Send an email to if you you're having problems, or, open an issue in the infra queue (https://www.drupal.org/project/infrastructure). Otherwise, we're probably not going to actually be made aware that anybody is having problems.

Drupal 7 does not cache pages for authenticated users. https://www.drupal.org/project/authcache would enable that, and then you'd have the privilege of making sure the page in question doesn't present one user's content to another.

For those looking for Rules functionality, which I also rely on heavily, I've recently been working with the new Business Rules module in D8.

It supports triggers/rules, conditions, actions, tokens, is documented and pluggable. It looks like someone got fed up with the state of Rules and just took matters into their own hands.

It's not a 100% drop in replacement by any means, but it seems to be working in the limited use cases I have so far. It felt a bit clunky at first, but after a couple of the video tutorials, things started making a lot more sense.

&#x200B;

Fivestar, or any sort of star rating module that the front-end user can use, voting api widgets hasn't worked on multiple sites I have it installed on to test.

https://www.drupal.org/project/fivestar

I have a list of modules I would like in d8 but i'll just add this one, as it seems like a lot of people could use it but hasn't been ported yet, it seems close but not quite over the line.

It only exposes the filters that are available in that view, where as that vocab might have hundreds of terms, but only a handful are used in that view

https://www.drupal.org/project/views_selective_filters

See the first half of this page: https://www.drupal.org/docs/7/howtos/how-to-make-a-simple-module-with-a-form-and-menu-link

Drupal 8?

I would avoid creating 100's of content types. Between custom blocks and creating smaller content types that work together via entity reference you should be able to avoid having tons of content types.

If you are going to run 1 big instance of Drupal for everyone then you will want to use some form of taxonomy based access control where you can create a vocabulary of departments then tag users and content to departments. https://www.drupal.org/project/group

You could also run the different departments as distinct sites that all share the same codebase (so 1 db per site).

I can't think of a module in the Project Usage page that isn't Drupal 8 compatible. I've reviewed most of those modules and they have Drupal 8 versions.

What are you using in your D7 sites that doesn't have a Drupal 8 version?

Moderately Critical:

> Remotely exploitable vulnerabilities that can compromise the system. Interaction (such as an administrator viewing a particular page) is required for this exploit to be successful. Exploits have not yet occurred on systems when vulnerability was disclosed. The exploit requires the user to be registered at the site and have some non-default permission, such as creating content.

> Previous examples include: Cross Site Scripting, Access bypass

From https://www.drupal.org/drupal-security-team/security-risk-levels-defined

Solr is the more matured solution - and you'll find a lot more documentation on the subject.

I've used both - and the Search API does a pretty decent job disambiguating both.

It's when you start loading up Search API supporting modules such as - https://www.drupal.org/project/search_api_autocomplete - which only has support for Solr.

For me it's a clear win to use Solr.

Two things :

• the update to 7.58 alone doesn't seem to be a breaking one (I've updated something like 40 sites, and a couple of old site from the 7.32 - the after drupalgeddon version - and i have got no problems)

• as stated here https://www.drupal.org/psa-2018-002 they say that there's an high probability that your site is already compromised.. So try to update and check for visible strange things.. And cross your fingers..

> Lightning is a dev module

module != distribution. Also, it's supported by Acquia. It wasn't in branch 3.x a year ago.

> This was your own mistake

Acquia's. I was hired to support the site and make upgrades. Spoke with Acquia support, and they agreed that the way forward was to remove Lightning, as lightning_media (among others) had been moved into core media in 8.4.x, and this site relies heavily upon it.

But thanks for the conclusion-jumping. ;)

I create a sub-theme from the Bootstrap theme since it is well supported.

The "vanilla" Bootstrap is fairly plain design-wise, but that better works for me since most of my sites need heavy custom visual design and UX. It's actually easier for me than trying to rework someone else's design into what I need.

https://www.drupal.org/project/bootstrap

historically speaking the Migrate API in D7, and ported to D8, is a tool to ingest new content into a drupal site. It is not a syncing tool between different sites or datasources seeking to resolve creating/deleting content between 2 sites. An example of a module/tool that tries to figure out what needs to be added/removed from 1 site and another is the Deploy module: https://www.drupal.org/project/deploy

The D7 migrate issue queue had a patch to do deletes from source data, but I don't believe that patch was ever finalized or ported to drupal 8.

Documentation could certainly be better, but there is a pretty easy example in the examples module and you can find examples on the module page for the csv helper. https://www.drupal.org/project/migrate_source_csv . I haven't checked it recently but I'm pretty sure his examples cover relationships and more complicated uses.

There's definitely a lot to learn and a lot to configure. I think my site setup script will eventually have to have dozens of add on modules install and configure for it to be worthwhile. Otherwise I don't see any real reason to abandon it yet. Btw, make sure you install admin_toolbar and toolbar_themes to make the nav bar sleeker and more functional. The stock toolbar in D8 makes me facepalm so hard.

Heres another favorite oldie but goodie: > [...] Acquia will not create a closed-source version of Drupal or compete with existing professional services companies who build Drupal-based websites. [...] https://www.drupal.org/node/196698

Dries's broken promises are countless.

“7 million reasons to consider democratising Drupal?” - https://www.drupal.org/node/202638

Also, check out Nedjo's post and links.

The last posts from Daniel Kudwien (sun) blog are also a good reference.

Yeah it's easier but you are then looking at another forced update soon. According to the release schedule D7 goes into security-fixes-only mode in 7 months, and will be end-of-life at the end of 2019.

These dates are not fixed in stone and might still change, but the current schedule indicates that all D7 sites will need to update to D8 in 2.5 years time.

D8 on the other hand will be supported for at least 4.5 years and the effort to update from D8 to D9 will be very low (ref Dries' blog post from last week: Making Drupal upgrades easy forever.

But your developers are absolutely right: upgrading from D6 to D7 is much easier than upgrading to D8 which requires most custom code to be rewritten. But upgrading directly to D8 will save you the effort of having to upgrade again in 2 years time.

One final remark which might not be obvious: upgrading from D7 to D8 is not much easier than upgrading directly from D6 to D8. Drupal has been completely rewritten for the D8 release so moving to D8 is always a significant effort. But a worthwhile one in my opinion. D8 is the most advanced content management system in existence right now.

Yeah I'm a site builder but the data is data.

>No one wants to work with d7 any more.

It appears that D8 is replacing D6 as the support ended and people felt forced to upgrade. D7 installs remain steady and D8 is not replacing it.

Overall Drupal usage has plateaued for the last several years so not many new sites are using Drupal. This makes a new version especially hard to catch on. D8 has been out for a while now and as of February 19 D8 still only accounts for 11% of Drupal installs. D7 accounts for 82%.

>Iirc for d7 site builders were similarly unsure until about the two year mark.

I remember this as well but I feel like this is going slower and/or not at all. Last time it was clear that D7 was growing rapidly. This time I'm not so sure. Maybe when support for D7 ends.

New module released for Drupal 7 Commerce, Commerce Abandoned Carts to send an email message to users who have abandoned their Drupal Commerce carts.

I'd recommend adding honeypot fields to your comment form, haven't used this module for comments but it should help a lot https://www.drupal.org/project/honeypot

As for the ip stuff, you'll want to add a validate callback to comment_form

What do you mean by complexity of Drupal? Backdrop is essentially Drupal!

Albeit voluntary, there are multiple ways to access support https://www.drupal.org/support. However if Backdrop works for you, go ahead and use it

Help your content creators by adding wysiwyg templates. Create simple code snippets, full layout templates, integrate your custom classes, tokens. Wishing I'd known about this a long time ago...

That's mostly true. However, the timeline for D8 will be much less than 6 months because core now contains so much. The major hold up with D7 was Views not being ready for more than 6 months.

Keep your eyes on https://www.drupal.org/project/contrib_tracker for the status of contrib projects.

It is possible to share tables between multisite instances. However it is not recommended due to the technical complications that may arise.

https://www.drupal.org/node/22267

I would recommend using some kind of identity management. You could for instance set up one site with all of the users and configure it to be a saml identity provider (idp). Then use the simplesamlphp module on all of the other sites to authenticate against the idp.

Easiest thing to do is use Delete All.

Or you could roll your own pretty easily with:

$result= db_query("SELECT nid FROM node"); foreach ($result as $record) { node_delete($record->nid); }

If you also need to set the nid counter back to 1, add:

db_query("ALTER TABLE node AUTO_INCREMENT=1");

Those two together as a drush one-liner:

drush php-eval '$result= db_query("SELECT nid FROM {node} AS n WHERE n.type = 'TYPE'"); foreach ($result as $record) {node_delete($record->nid);} db_query("ALTER TABLE node AUTO_INCREMENT=1");'

Good news: your wish is already policy for 8.0.0 ! We'll be using semantic versioning so that API breaks only happen between major versions. You can expect scheduled releases for patch versions (8.0.X) every month, and minor versions (8.X.0) every 6 months. We will guarantee no api breaks in patch releases, and "near-100%" no api breaks in minor versions. The core dev team will remain focused on the 8 branch, making these incremental changes, for as long as possible.

After a year or so we will open 9.x for development of major api breaking features. When the first major api breaking feature is completed, it will form the basis for the 9.X branch, and the next minor version of 8.X will be marked as the "long term support" version. This LTS version will remain supported until 9.X LTS is released, which means until 10.X starts.

The full explanation has a lot more detail. I can't think of another project that does this better, but I'm all ears if you think if an improvement!

TL;DR Drupal 8.0.0 will use semantic versioning, so backwards compatibility breaks should be extremely rare to nonexistent for the life of 8.x (6 years or so).