Drupal

Migrate Process S3

New Drupal Modules - 7 January 2019 - 2:16pm
Categories: Drupal

Palantir: Federated Search: The Demo

Planet Drupal - 7 January 2019 - 12:57pm
Federated Search: The Demo brandt Mon, 01/07/2019 - 14:57 Ken Rickard and Avi Schwab Jan 7, 2019

See Palantir’s federated search application in action.

We recently published a blog post introducing our solution to Google Search Appliance being discontinued—an open source application we built and named Federated Search. If you haven’t already, we recommend checking out that first blog post to get the basics on how we built the application and why. Read on here to learn how you can see for yourself what the application does.

Search API Federated Solr is a complex application, and the best way to understand what's going on is to see it in action! Since the application requires a Solr instance in addition to a number of Drupal modules, we're not able to use Simplytest.me for demos. Instead, we've bundled all of the pieces together with Palantir's open source dev tools — the-vagrant and the-build — for a seamless demo experience that runs in a local virtual machine (VM) running on Vagrant. Head to GitHub to review the requirements, and then clone the repo and get started.

Setting up the environment

The-vagrant is a customizable vagrant environment that can be built into a project from scratch or easily retrofit an existing project (such as a new support client). On first setup, a handy install wizard takes users through a configuration process to choose hostnames, enable optional services like Solr, and enable further customization through Ansible tasks. The-vagrant is capable of handling single site, multi-site, or multiple-site (many docroot) setups in a single box, so it was a perfect match for our Federated Search environment.

The-build is a set of reusable phing targets for building Drupal projects. Once our VM is up and running, we use a standard set of these tasks to automate a number of complex tasks, such as:

  • Copying settings and services files into Drupal sites directories
  • Installing Drupal using an install profile and any existing config
  • Running post-install tasks like migrations
  • Running test suites
  • Importing databases from hosting environments
  • Deploying code to hosting environments

We have a shared set of phing targets that provide the foundation for many of these tasks, and each project extends them to meet their specific needs.

Building the demo

The Federated Search Demo repo builds a simulated multiple site environment, with a Solr server to boot, in the comfort of your own VM. Our demo site is expressly designed for both testing and development.

Because the application supports multisite, Domain Access, and standalone sites, we wanted to be able to demo (and develop for) all possible scenarios. To this end, the demo contains four docroots: Drupal 7 standalone, Drupal 7 Domain Access (coming soon), Drupal 8 standalone, Drupal 8 Domain Access. The D8 sites use the amazing core Umami profile to demo with real content, while the D7 site uses Devel Generate for some lorem ipsum-based content.

As of this writing, Domain Access is supported in the Drupal 7 module code, but not installed in the demo profile. The reverse is true for Drupal 8, and making the Drupal 8 version of Federated Search support Domain Access is under active development. We literally had to build the VM in order to finish those features!

There are a lot of dependencies involved, so let’s go to an application diagram:

There’s a lot going on there, but we suggest grabbing the repo and seeing for yourself.

What to expect

Once you clone the demo repo, there are full instructions on getting the VM and Drupal up and running. After installing all of the sites, you can start by visiting http://d8.fs-demo.local and use the search box to test a search (maybe try mushrooms, yum). You should see the React-powered search page with your results and a number of filters on the left side which you can experiment with.

Once you see the search results, you can dig in to how it works. In the Search App Settings (found at admin/config/search-api-federated-solr/search-app/settings) you can control a number of pieces of how the search page is displayed including it’s route and title. We set the page to default to ‘/search-app’ so as not to conflict with the default core configuration. Any changes made on this page should clear the cache for the search application and immediately be reflected on refresh.

Next, you may want to see how data is indexed. The search index field config page (found at admin/config/search/search-api/index/federated_search_index/fields) will show a list of all of the mapped fields the site is sending to the index. Clicking on Edit will show you the details of each, showing each bundle in the site and how it’s being sent to the index. The Edit modal includes a token picker, showing the true power of this tool—the ability to use tokens or text at the bundle level to send data to our index.

From this screen, try editing the config for a field, adding a token or changing a format. Once you do that, Search API will prompt you to re-index your data.

You can do so, then refresh the search results to see the changes. You might also want to inspect the raw data being sent to Solr. To do that, visit the Solr dashboard (at http://federated-search-demo.local:8983/solr/#/drupal8/query) and execute the default query. There you can see all of the fields being sent to the index.

Coming back to the search page, inspecting the results with the React Dev Tools will help you understand how the application is handling data. Once you install the browser extension, you can inspect the app, view the React components, see props being passed through the stack, and more. For an even deeper dive into the React application, you can clone that project and build it locally.

Contributing

In addition to providing a full demo environment, this repo also serves as a development environment for Search API Federated Solr and Search API Field Map. While those modules are installed by composer, the repo also links them into the ‘/src/’ directory for easy access. From there, you can add a GitHub remote or create patches for Drupal.org.

Issues for the demo can be raised on GitHub, and issues for the modules can be on either GitHub or Drupal.org. Be sure to read the handbook on Drupal.org for even more detail on how the system works.

Learn more about Federated Search in this presentation from Decoupled Days (or just view the slides).

Development Drupal Open Source
Categories: Drupal

Palantir: Introducing Federated Search

Planet Drupal - 7 January 2019 - 11:38am
Introducing Federated Search brandt Mon, 01/07/2019 - 13:38 Ken Rickard and Avi Schwab Jan 7, 2019

Search API Federated Solr is Palantir.net’s open source solution to federated search.

Last year, Google announced Google Search Appliance would be discontinued. This announcement means that enterprise clients needing a simple yet customizable search application for their internal properties will be left without a solution some time in 2019.

As the request of an existing client, Palantir has worked for the past year to produce a replacement for the GSA and other federated search applications using open-source tools. We abstracted this project into a reusable product to index and serve data across disparate data sources, Drupal and otherwise, and we’re now happy to share it with the community.

What is Federated Search?

We have created an application that allows you to index multiple Drupal (or other) sites to a single search application, and then serve the results out in a consistent manner with a drop-in application that will work on any site where you’re able to add a little CSS and JavaScript.

Federated Search is being released publicly as an open source solution to a common problem. It works out-of-the-box, and can also be customized. There are three main parts to the product:

  • Content indexing via Drupal integration (provided)
  • Result serving via React application (provided)
  • Data storage in a Solr backend (required; we can recommend SearchStax as an option.)
How was Federated Search built?

Every search application, no matter what the implementation, has three main parts: the source, the index, and the results.

Working from the results backward, we began with identifying a schema in which all of our source data would be stored. A basic review of search pages across the internet reveals a fairly common set of features. A title, some descriptive text, and a link are the absolute minimum for displaying search results. Some extra metadata like an image, date, and type are also useful to give the user a richer experience and some filter criteria. Finally, since we’re searching across sites, we’ll need some data about where the item comes from.

With that schema in mind, and knowing Drupal would be our data source, we identified a need to get data from some unknown structure in Drupal (because every site might have vastly different content types) into a fixed set of buckets. Since much of the terminology is the same, the Metatag module quickly came to mind — Metatag allows users to take data from Drupal fields using Tokens and output it into specific meta-tags on the site. With that same pattern in mind, we built Search API Field Map. This module allows us to use tokens to set bundle-level patterns, which all get indexed into the same field in our index.

At Palantir, search is part of every project. We’ve implemented numerous custom and complex search configurations, and almost every time we lean on Apache Solr for our backend. Solr is a CMS-agnostic search index that has a well-supported and robust existing toolchain for Drupal. Search API and Search API Solr provided a solid groundwork from which to build our source plugins, so then the last step was getting our data out. Solr comes out of the box with “Response Writers” that cover almost every known data format, so our options were wide open.

We knew we wanted to provide our client with a CMS-agnostic drop-in interface and that we had a data source that’s fluent in JSON, so that immediately pointed us in the direction of a Javascript framework. The JS space is incredibly dense at the moment, but after some investigation, we settled on React to provide us the robust data management and user interface for our search application.

We started with an existing framework to provide the query handlers and basic front-end components, then extended it with our own set of component packs to build out the user interface. Search API Federated Solr provides the React application as a Drupal library, adds a search block, and surfaces some custom per-site configuration for the search application.

A Flexible, Open Source Search Solution

With Drupal, Solr, and React working together, we’re able to index data from completely arbitrary sources, standardize it, and then output it in an easily consumable way. This approach means more flexibility for site administrators and a cleaner experience for users.

A number of commercial applications exist to provide this functionality, but our solution provides a number of benefits:

  • Keeping the data source tightly coupled with Drupal allows for maximum customization and access to the source content.
  • Providing a decoupled front-end allows us to surface results anywhere, even outside of Drupal.
  • Being built on 100% open-source code allows for community improvement and sharing.
How can you use this or download the code?

Between the Drupal modules and React code, there’s a lot going on to make this application work, and even with those, you’ll still need to bring your own Solr backend to index the data. Luckily, we’ve put all those pieces together into a fully functional demo box using Palantir’s open source Vagrant environment and build tasks.

If you’d like to inspect the pieces individually, here they are:

Palantir plans to maintain these projects as a cohesive unit moving forward, and pull requests or D.o issues on the projects above are always welcome.

Does it have to be a Drupal site?

No! While we provide everything needed to index a Drupal 8 or Drupal 7 site, there’s no reason you can’t configure an additional data source to send content to the same Solr index, as long as it conforms to the required schema. The front-end is also CMS-agnostic, so you could search Drupal sites from Wordpress, another CMS, or even from a statically generated site.

You can read how to see Federated Search in action in our Demo blog post or learn more about Federated Search in this presentation from Decoupled Days (or just view the slides).

Development Drupal Open Source Industries Higher Education
Categories: Drupal

Marketing technologies for engineers, not marketers

Dries Buytaert - 7 January 2019 - 9:12am

Casey Winters writes about why marketing technology companies should change their target customer from marketers to engineers. If you are like me — an engineer building a marketing technology company — Casey's blog post is guaranteed to generate some "ahas".

Categories: Drupal

Tidelift raises $25 million series B

Dries Buytaert - 7 January 2019 - 8:30am

Tidelift, which provides organizations with commercial-grade support for Open Source software and pays part of the proceeds to software maintainers, raises a $25 million Series B. I hadn't heard about Tidelift before, but it turns out their office is 300 meters from Acquia's. I reached out and we're going to grab a coffee soon.

Categories: Drupal

Acro Media: Online Cannabis Sales: Open Source vs. SaaS

Planet Drupal - 7 January 2019 - 7:45am
What we can learn from day one of legal online cannabis sales in Canada


On October 17, 2018, Canada took a progressive step forward as the sale of recreational cannabis became legal for the entire country. It was the end of a prohibition, sparking a wave of new business opportunity. It’s hard to find official numbers for Canada as a whole, but it’s estimated that there were about 212,000 first-day sales across the country worth approximately $28 million! We thought it would be a good opportunity to show some of the benefits of open source vs. SaaS solutions for online cannabis.

First off, It’s hard to say exactly how many transactions occurred online for Canada as a whole. It’s up to each province and territory to decide how they want sales to proceed and stats are quite limited at this point. We do, however, have solid information for a couple smaller provinces that we can start with. Then we can expand with speculation after that.

What we know Cannabis Yukon

Cannabis Yukon, the Yukon government run retail outlet, had a combined online and in-store sales totalling about $59,900 (source). About 25% of that number, roughly $15,000, was transacted online. The online retail outlet uses the open source platform Drupal.

PEI Cannabis

PEI Cannabis, the Prince Edward Island government run retail outlet, had a combined online and in-store sales totalling about $152,000 (source). About 7% of that number, roughly $21,000, was transacted online. The online retail outlet uses the SaaS platform Shopify. It’s interesting to note that Shopify also runs the provincial online pot shops for Ontario, British Columbia and Newfoundland.

Functionality is the same

All ecommerce cannabis outlets in Canada, government or private, are going to have the same features. They need to block access to minors, they need to sell products based on weight and they need to restrict the maximum amount of cannabis an individual can purchase at one time. All other functionality required is standard ecommerce. Functionality-wise, Cannabis Yukon and PEI Cannabis do the same thing. Whether it’s open source or SaaS, there isn’t an edge either way there.

Where open source has the advantage

Where it gets interesting, and where the Yukon Government is in a great position to succeed, is commerce architecture and service fees. These are a couple of big reasons why open source is really catching fire in the ecommerce marketplace.

Commerce architecture

Yukon Cannabis is built on the Drupal platform. It’s open source software meaning there are no service fees to use and anyone who uses it can customize and innovate the software however they like. Development can be done in-house or with any 3rd party development agency familiar with the underlying code, mainly PHP.

An advantage to using a platform like Drupal is that it can integrate and talk to other services your operation may use for accounting, marketing, inventory, customer management, etc. Integrations and automation eliminate swivel chair processes that restrict business growth.

PEI Cannabis, on the other hand, is somewhat vendor locked using the Shopify platform. Shopify does have a rich ecosystem of integrations, but if there’s ever a need to develop a new integration, PEI Cannabis is restricted to dealing with only Shopify or their small group of partners. That usually means high cost.

Service fees

When a sale is made using a SaaS platform, a certain percentage of the sale is lost to taxes and additional platform specific transaction fees. In the case of Shopify Plus, the enterprise fee structure is $2,000 per month + 0.25% per transaction, capping at a maximum of $42,000 per month (source). You can optionally use ‘Shopify Payments’ instead which carries a transaction fee of 1.6% + 30 cents per transaction. This would be a better way to go only if you don’t require any other payment gateways, but in our experience that isn’t the case. Finally, in addition to Shopify’s fees, the platform has an extension library to extend the functionality to your store. Most of these extensions carry their own monthly fee and there’s a very good chance you would need some of them.

With SaaS ecommerce platforms like Shopify, year after year the cost of ownership increases. At minimum, the yearly fees paid to Shopify amount to $24,000 and can rise as high as $480,000. That doesn’t include any additional extensions that you use or any payment gateway fees. PEI Cannabis must pay these fees (and so do the governments of BC, Ontario and Newfoundland who also use Shopify).

Open source ecommerce platforms, on the other hand, don’t necessarily have any of these additional fees. Aside from the standard payment gateway fees and hosting fees, Yukon Cannabis pays no additional monthly or yearly licensing fee to use their ecommerce platform. Whether they sell $15,000 or $15 million, the investment that they’ve made into the development of their website should pay for itself quite quickly, potentially within a year.

Furthermore, provincial government cannabis retailers are essentially public companies. A large portion of the profit made is to be distributed at the provincial and federal levels to support various public services and initiatives. By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

Service fee breakdown

Here’s a rough breakdown of potential monthly and annual platform service fees based on some of the numbers we know. We know the combined (online and in-store) sales from day one were elevated due to the hype of legalization, and we know that BC sales dropped by 70% on day two. For our fee breakdown, we’ll take the 70% reduced amount from the combined total numbers we know and use that to calculate a 30 day monthly sales estimate. We’ll use the combined total because most ecommerce platforms also support an official in-store point of sale component. This is all speculation of course, but it still shows realistic ecommerce sales numbers and how service fees accumulate based on them.

While the numbers shown below may appear to be quite large at first, Statistics Canada, the national statistics government agency, predicted back in September that legal cannabis sales for the first 3 months will be between $816 million and $1 billion nationwide. If that ends up being true, the numbers below would actually be grossly underestimated!

Est. Monthly Sales
Based on 30% of day one total x 30 days (XX/100 x 30) x 30 Open source
Annual and Monthly Fee: 0% Shopify Plus
Monthly including transaction fee
(calculator) Shopify Plus
Annual 
(monthly x 12) Yukon Cannabis
30 day est: $539,100
Day one: $59,900 $0 $2,994.31 $35,931.72 PEI Cannabis
30 day est: $1,368,000
Day one: $152,000 $0 $4523.13 $54,277.56 Nova Scotia
30 day est: $5,940,000
Day one: $660,000 $0 $12,955.69 $155,468.28 Alberta
30 day est: $6,870,000
Day one: $730,000 $0 $14,670.97 $176,051.64 All of Canada *
30 day est: $252,000,000
Day one: $28,000,000 $0 $40,000 (cap)  $480,000 (cap)

* The government agency Statistics Canada predicts that legal cannabis sales in Canada will be between $816 million and $1 billion (source).

Where SaaS has the advantage

The biggest advantage that SaaS such as Shopify has over open source is the speed at which you can get your product to market and the simplicity of use.

If you’re just starting out and need to get an ecommerce site up and running quick, these services are turn-key and can get your product to market fast. The website management interface is clean and easy to use, and most people can do what they need to do with little to no training.

There is a reason why companies like Shopify are quite dominant and it’s largely because of the simplicity. While we strongly believe that you shouldn’t choose your platform based on features, many people are willing to pay extra to be able to do it all themselves.

Takeaways

Watching a new industry unfold in Canada has been fun. It’s interesting to see that both open source and SaaS has found its way into the legal cannabis marketplace. Clearly both open source and SaaS work for this industry, it’s more about what you’re willing to pay and what ecommerce ecosystem you think is best for your business and its future growth.

If you’re thinking about online cannabis retail (or any other online retail for that matter), Acro Media has the expertise and processes in place to help guide you to online commerce success. Try our Digital Commerce Assessment Tool to uncover problematic areas within your digital commerce operations.

Categories: Drupal

Lullabot: JSON:API 2.0 Has Been Released

Planet Drupal - 7 January 2019 - 6:08am

Note: This article is a re-post from Mateu's personal blog.

I have been very vocal about the JSON:API module. I wrote articles, recorded videos, spoke at conferences, wrote extending software, and at some point, I proposed to add JSON:API into Drupal core. Then Wim and Gabe joined the JSON:API team as part of their daily job. That meant that while they took care of most of the issues in the JSON:API queue, I could attend the other API-First projects more successfully. I have not left the JSON:API project by any means, on the contrary, I'm more involved than before. However, I have just transitioned my involvement to feature design and feature sign-off, sprinkled with the occasional development. Wim and Gabe have not only been very empathic and supportive with my situation, but they have also been taking a lot of ownership of the project. JSON:API is not my baby anymore, instead we now have joint custody of our JSON:API baby.

As a result of this collaboration Gabe, Wim and I have tagged a stable release of the second version of the JSON:API module. This took a humongous amount of work, but we are very pleased with the result. This has been a long journey, and we are finally there. The JSON:API maintainers are very excited about it.

I know that switching to a new major version is always a little bit scary. You update the module and hope for the best. With major version upgrades, there is no guarantee that your use of the module is still going to work. This is unfortunate as a site owner, but including breaking changes is often the best solution for the module's maintenance and to add new features. The JSON:API maintainers are aware of this. I have gone through the process myself and I have been frustrated by it. This is why we have tried to make the upgrade process as smooth as possible.

What Changed?

If you are a long-time Drupal developer you have probably wondered how do I do this D7 thing in D8? When that happens, the best solution is to search a change record for Drupal core to see if it change since Drupal 7. The change records are a fantastic tool to track the things changed in each release. Change records allow you to only consider the issues that have user-facing changes, avoiding lots of noise of internal changes and bug fixes. In summary, they let users understand how to migrate from one version to another.

Very few contributed modules use change records. This may be because module maintainers are unaware of this feature for contrib. It could also be because maintaining a module is a big burden and manually writing change records is yet another time-consuming task. The JSON:API module has comprehensive change records on all the things you need to pay attention when upgrading to JSON:API 2.0.

undefined

As I mentioned above, if you want to understand what has changed since JSON:API 8.x-1.24 you only need to visit the change records page for JSON:API. However, I want to highlight some important changes.

Config Entity Mutation is now in JSON:API Extras

This is no longer possible only using JSON:API. This feature was removed because Entity API does a great job ensuring that access rules are respected, but the Configuration Entity API does not support validation of configuration entities yet. That means the responsibility of validation falls on the client, which has security and data integrity implications. We felt we ought to move this feature to JSON:API Extras, given that JSON:API 2.x will be added into Drupal core.

No More Custom Field Type Normalizers

This is by far the most controversial change. Even though custom normalizers for JSON:API have been strongly discouraged for a while, JSON:API 2.x will enforce that. Sites that have been in violation of the recommendation will now need to refactor to supported patterns. This was driven by the limitations of the serialization component in Symfony. In particular, we aim to make it possible to derive a consistent schema per resource type. I explained why this is important in this article.

Supported patterns are:

  • Create a computed field. Note that a true computed field will be calculated on every entity load, which may be a good or a bad thing depending on the use case. You can also create stored fields that are calculated on entity presave. The linked documentation has examples for both methods.
  • Write a normalizer at the Data Type level, instead of field or entity level. As a benefit, this normalizer will also work in core REST!
  • Create a Field Enhancer plugin like these, using JSON:API Extras. This is the most similar pattern, it enforces you to define the schema of the enhancer.
File URLs

JSON:API pioneered the idea of having a computed url field for file entities that an external application can use without modifications. Ever since this feature has made it into core, with some minor modifications. Now the url is no longer a computed field, but a computed property on the uri field.

Special Properties

The official JSON:API specification reserves the type and id keys. These keys cannot exist inside of the attributes or relationships sections of a resource object. That's why we are now prepending {entity_type}_ to the key name when those are found. In addition to that, internal fields like the entity ID (nid, tid, etc.) will have drupal_internal__ prepended to them. Finally, we have decided to omit the uuid field given that it already is the resource ID.

Final Goodbye to _format

JSON:API 1.x dropped the need to have the unpopular _format parameter in the URL. Instead, it allowed the more standard Accept: application/vnd.api+json to be used for format negotiation. JSON:API 2.x continues this pattern. This header is now required to have cacheable 4XX error responses, which is an important performance improvement.

Benefits of Upgrading

You have seen that these changes are not very disruptive, and even when they are, it is very simple to upgrade to the new patterns. This will allow you to upgrade to the new version with relative ease. Once you've done that you will notice some immediate benefits:

  • Performance improvements. Performance improved overall, but especially when using filtering, includes and sparse fieldsets. Some of those with the help of early adopters during the RC period!
  • Better compatibility with JSON:API clients. That's because JSON:API 2.x also fixes several spec compliance edge case issues.
  • We pledge that you'll be able to transition cleanly to JSON:API in core. This is especially important for future-proofing your sites today.
Benefits of Starting a New Project with the Old JSON:API 1.x

There are truly none. Version 2.x builds on top of 1.x so it carries all the goodness of 1.x plus all the improvements.

If you are starting a new project, you should use JSON:API 2.x.

JSON:API 2.x is what new installs of Contenta CMS will get, and remember that Contenta CMS ships with the most up-to-date recommendations in decoupled Drupal. Star the project in GitHub and keep an eye on it here, if you want.

What Comes Next?

Our highest priority at this point is the inclusion of JSON:API in Drupal core. That means that most of our efforts will be focused on responding to feedback to the core patch and making sure that it does not get stalled.

In addition to that we will likely tag JSON:API 2.1 very shortly after JSON:API 2.0. That will include:

  1. Binary file uploads using JSON:API.
  2. Support for version negotiation. Allows latest or default revision to be retrieved. Supports the Content Moderation module in core. This will be instrumental in decoupled preview systems.

Our roadmap includes:

  1. Full support for revisions, including accessing a history of revisions. Mutating revisions is blocked on Drupal core providing a revision access API.
  2. Full support for translations. That means that you will be able to create and update translations using JSON:API. That adds on top of the current ability to GET translated entities.
  3. Improvements in hypermedia support. In particular, we aim to include extension points so Drupal sites can include useful related links like add-to-cart, view-on-web, track-purchase, etc.
  4. Self-sufficient schema generation. Right now we rely on the Schemata module in order to generate schemas for the JSON:API resources. That schema is used by OpenAPI to generate documentation and the Admin UI initiative to auto-generate forms. We aim to have more reliable schemas without external dependencies.
  5. More performance improvements. Because JSON:API only provides an HTTP API, implementation details are free to change. This already enabled major performance improvements, but we believe it can still be significantly improved. An example is caching partial serializations.
How Can You Help?

The JSON:API project page has a list of ways you can help, but here are several specific things you can do if you would like to contribute right away:

  1. Write an experience report. This is a Drupal.org issue in the JSON:API queue that summarizes the things that you've done with JSON:API, what you liked, and what we can improve. You can see examples of those here. We have improved the module greatly thanks to these in the past. Help us help you!
  2. Help us spread the word. Tweet about this article, blog about the module, promote the JSON:API tooling in JavaScript, etc.
  3. Review the core patch.
  4. Jump into the issue queue to write documentation, propose features, author patches, review code, etc.

Photo by Sagar Patil on Unsplash.

Categories: Drupal

Wim Leers: JSON:API module version two

Planet Drupal - 7 January 2019 - 6:08am

Mateu, Gabe and I just released JSON:API 2.0!

Read more about it on Mateu’s blog.

I’m proud of what we’ve achieved. I’m excited to see more projects use it. And I’m confident that we’ll be able to add lots of features in the coming years, without breaking backwards compatibility. I was blown away just now while generating release notes: apparently 63 people contributed. I never realized it was that many. Thanks to all of you :)

I had a bottle of Catalan Ratafia (which has a fascinating history) waiting to celebrate the occasion. Why Ratafia? Mateu is the founder of this module and lives in Mallorca, in Catalunya. Txin txin!

If you want to read more about how it reached this point, see the July, October, November and December blog posts I did about our progress.

Categories: Drupal

Welcome Message

New Drupal Modules - 7 January 2019 - 5:32am
Categories: Drupal

Specbee: Drupal 8 Now or Drupal 9 later? What’s the right thing to do?

Planet Drupal - 7 January 2019 - 5:02am

Did you know, on an average an adult makes about 35000 decisions each day?! And suddenly, life feels more difficult. Most are mundane but taking the right step towards an important decision can turn you into a winner. Since the release of Drupal 8 in November 2015, Drupal website owners have been in a dilemma. To upgrade or not to upgrade. To migrate to Drupal 8 now or simply wait till Drupal 9 releases and completely skip 8. And to make things more knotty, there are PHP, Symfony and other version upgrades to keep track of too.

At this point, you might wonder why choose or stick with Drupal at all when everything seems so complex and tedious. Why shouldn’t I just switch to a rather simpler CMS where I can sit back and just let my content work its magic, you ask? Here’s the thing – Drupal is an open-source content management framework that is best known for the security, robustness and flexibility it offers. Without constant and consistent updates and patches, Drupal wouldn’t have been the relevant, dependable and trusted CMS that it is today. This continuous innovation approach has helped Drupal in offering new Drupal features, advanced functionalities and security patches with every minor release.

Categories: Drupal

Seasonal Product Recommendations

New Drupal Modules - 7 January 2019 - 2:57am

This module allows you to deliver a more personalized experience to your customers by sending product recommendations on the basis of the prevalent season to them. This will take the customer experience on your eCommerce website to the next level. Customers from different locations have different needs. Then why not customize the recommendations for them, accordingly.

Categories: Drupal

Testingdeepanker

New Drupal Modules - 7 January 2019 - 2:23am

This is testing and i will delete it.

Categories: Drupal

Podcast (using Views)

New Drupal Modules - 6 January 2019 - 11:14pm

Podcasts is a module that aims to create a Podcast feed for your site using Views.

Categories: Drupal

CiviCRM Blog: Webform CiviCRM Integration: new features added in 2018 and looking ahead to 2019

Planet Drupal - 6 January 2019 - 12:39pm

2018 was a big year for Webform CiviCRM module. I wanted to take a moment to highlight some of the new features that were added in 2018 (with some examples/screenshots) and take a look at what's to come in 2019!

Webform CiviCRM Integration - what is this?

Webform CiviCRM is a Drupal module that in a nutshell exposes CiviCRM APIs (with which you can create CiviCRM contacts, contributions, memberships, participant registrations, activities - just about any CiviCRM Entity programmatically) to the powerful Drupal Webform module - a very popular (over 450,000 Drupal sites are using it) and highly configurable drag and drop form builder. Webform CiviCRM itself is a popular module - over 3,000 CiviCRM projects are using it. That's more users/sites than the Mosaico Extension has! Webform CiviCRM was invented by Coleman Watts (of the CiviCRM Core Team) and is supported by the CiviCRM community:  https://www.drupal.org/project/webform_civicrm

2018 - highlights is:pr is:closed updated:>2018-01-01 -> 88 closed! Some highlights include:
  • enhancements to recurring contributions via Webform CiviCRM (thanks to Biodynamics Association (USA) for co-funding this) - you can now configure your webform such that you can pay any amount (Event, Membership) in instalments as well as start a regular recurring open-ended Donation. An example of this would be swim club fees -> a full season is 10 months and costs $3,000 for the entire year. You can now configure your webform such that parents can sign up their child(ren) for Memberships/Events -> and select to pay all at once or in e.g. 10 instalments of $300/month.
  • Stripe support (thanks to contributions by Matthew Wire from MJW Consulting) - Matt has been doing a lot of work on the Stripe Extension and we've been supportive of changes he has PR-ed to Webform Civicrm module.  This means that Webform CiviCRM is now compatible with all major in-line Payment Processors: Stripe, iATS Payments and PayPal Pro.
  • being able to configure financial types (thanks to PEMAC (Canada) for funding this) - it is now possible to e.g. charge the correct Sales Tax [which is defined per Financial Type] based on a member's Province/location.



  • added line item support (thanks to Wilderness Committee (Canada) for funding this) - it is now possible to add up to 5 additional lineItems for one Contribution. So you can now do things like: make a donation, purchase a calendar, pay for postage - all on the same webform - and in combination with the financial type improvements - you can control the financial types for every line item, ensuring that (in our example) - the donation becomes eligible for Charitable Tax Receipting but the calendar purchase and the postage do not. 
  • numerous improvements re: cases, activities, memberships (thanks to people at Compucorp and Fuzion, and many others)
  • many other improvements - I apologize for missing anything/anyone!
  • Coleman and I ran a 2h sold-out Workshop on Webform CiviCRM at CiviCamp Calgary 2018. We covered lots of features and in-hindsight wished we had recorded it. Next time! Amongst many other items we covered how the Registration form for CiviCamp Calgary 2018 was built (allowing multiple participants to be signed up for multiple events and also including a Partner discount code field).


Also filed under 2018 highlights: Jacob Rockowitz officially released his Drupal 8 version of Drupal webform module - it includes wicked new features that make webforms more portable than ever and new fields like signature fields and my favourite: automated country flags for phone numbers (see screenshot further down).

Looking ahead at 2019 How can user organizations Contribute?

 

                                    DrupalExtensions
Categories: Drupal

D7ES

New Drupal Modules - 6 January 2019 - 11:20am
Categories: Drupal

The Accidental Coder: 8: Compound (bundled) fields - your new best friend

Planet Drupal - 6 January 2019 - 9:15am
8: Compound (bundled) fields - your new best friend j ayen green Sun, 01/06/2019 - 12:15
Categories: Drupal

Who Bought What (Ubercart)

New Drupal Modules - 6 January 2019 - 8:53am

This is for Ubercart. If you are using Ubercart to sell tickets or entries to an event or perhaps a race, it's very helpful to have a list, per item, of who bought what. For a competition, this will become an entry list. For a performance, this may become your will-call attendance list.

You may simply want to know who bought what! Who are the purchasers of a given item can be useful in any of a number of instances... recalls, promotions, and the like.

Categories: Drupal

OpenSense Labs: Drupal Bringing Justice to Your Law Firm Website

Planet Drupal - 6 January 2019 - 4:15am
Drupal Bringing Justice to Your Law Firm Website Vasundhra Sun, 01/06/2019 - 17:45

Unequivocally, 21st century is considered as an innovative era, and there is no doubt to the fact that having a website contributes largely to the innovation. 

Owning a website is like owning a business card, it is an essential segment that shouts “I am a professional, who is open for business”. So, if you have a website, it would typically be the very first interaction for an individual that would create an impression for your potential client. 

When it comes to a law firm website, these potential clients always look for reliability and confidentiality. They need a strong shoulder to lean on, and nothing works better than Drupal. 


If you ask - Why Drupal? 

Well, mainly because a law firm website would always wish for safety against hackers and smooth performance over high load. Drupal creates a solid and reliable impression when it comes to both these sectors. 

Drupal is a Good Option for Your Law Firm Website

According to a survey conducted by “Legal Trend Reports”, nearly 37 percent of the population search for a lawyer online. Which means that for succeeding in an industry it is important to have an attractive, robust and secure website.

And this is how Drupal does the task. 

Builds Togetherness with the Community 

Drupal is a free and open source content management system with an active community constantly creating free elements for the website in the form of modules, themes, and distributions.

The large community grinds Drupal like a valuable gem to absolute perfection by constantly keeping its hand on modern innovations.

The open source platform is supported by an active community of more than 1 million members who are constantly trying to make it more flexible than other platforms in the market. The CMS has been providing immense support to its users by presenting a helping hand in form of creating documentation, sharing networking opportunities, granting them with valuable modules etc.


Headless Drupal awarding you with user interaction 

Whether you call it “Decoupled” or “Headless” content management system, using Drupal as your central content service can power up your entire application and device ecosystem.

The mantra of the web development strategy “Write once and publish everywhere” has been grabbing the eyes of several law firm website owners.

The concept of decoupling also implies the managing of different content layers separately, with an agnostic presentation layer. To be precise, it is the communication between backend and the frontend via API.

Rocky mountain victim law center (RMVLC) is a great example of this methodology. The website houses a program which is known as the Legal Information Network of Colorado (LINC). On the basis of a series of questions, this web app provided people with exact legal information and resources. The goal of this program was to empower victims of crime. A better way to make them understand their legal options in the aftermath of victimization. The victims were presented with the advantage to answer a series of questions about the mishap which resulted in a custom list of actionable resources.

Although Drupal gave the power to the application to manage content on the backend. Ember.js (an open source, free JavaScript client-side framework used for developing web applications) was also used in the front end to provide the user with a highly interactive experience.

The Decoupled Approach allowed LINC to leverage the strengths of both - frontend as well as backend 

Access your website anywhere 

When we talk about “better user experience” - mobile compatible websites has turned out to be an important factor for marketers, organizations, corporates, and advertisers

This is because according to FindLaw studies, nearly 72 percent of mobile users say that it is important for a website to be fully optimized for mobile use. That means that the website should be accessible to people in any device. 

Drupal is the CMS which provides the users with multiple themes that are mobile responsive and layout centric. The platform has replaced PHP template with all new Twig template in its latest update which not only makes it easy and flexible for the users to use but also provides them with fast, secure, and manageable website. 

Thereby, Drupal's responsive designs have helped websites to respond to each visitor’s needs by adapting its presentation based on the size and capabilities of the device which is being used. 

The website of JCWI, which aims to provide justice to all the immigrants, is built on DrupalMastering Multiple sites 

Large law firm websites consist of many committees and promoting any desired initiative on the main website for an individual attorney could be a big hassle. Therefore, the only solution to the whole scenario is to have an individual website or a blog that is separate from the main website yet a part of it. 

Therefore, Drupal contributes largely to simplify the management of the websites with the help of the multisite feature. It allows you to serve multiple sites with the help of single codebase. The requirement is only to maintain one copy of Drupal core and, of course, the contributed modules. In other words, it brings about a manageable code across multiple sites and brings agility while launching new sites. 

A great example of the multisite feature is the Legal services corporation which provides legal assistance to low-income citizens. The website is a collection of six other sites with the main agenda of providing easy maintenance to the LCS staff while they update the website. Therefore, Drupal was chosen based on the fact that it powers multisite functionality and consisted of one Drupal installation. Not only this but the site also leveraged multilingual support and was compliant with Section 508 of the US Rehabilitation Act. 

Decoding Multiple Languages 

As an attorney, it is possible that you might practice in an area where your client speaks different languages. A translator in such a situation becomes an important factor in the whole journey of communication. 

Similar is the case with the audiences that are surfing online. It is necessary to add a multilingual capability to your law firm website due to the fact there is a diverse audience that does not have English as their preferred language. The multilingual feature here not only makes it easy for those users to understand your website content, but it also doubles your chance of being spotted in the Google search result.

Drupal is one of those CMSes that emerges out as a sword for all the website owners with a power of multilingual feature. It grants them with a striking number of over 90 languages that has a built-in translation core.

Apart from translating your content, Drupal also translates all the fields, forms and error messages. The new version of Drupal consists of 4 inbuilt multilingual modules.

Managing Language

This module lets the user pick the choice in which they desire to change the website. It consists of 96 languages in its bar. The language configuration has been streamlined to the user. It assigns languages to everything, from taxonomy terms to administrative language. 

Interface Translation 

It provides the user with a central directory to manage the interface. It has a built-in translation UI for simplifying the content. By allowing the automated downloads and updates, the users easily translate the interface. 

Content Translation 

This module is applicable to all the contents. It allows the user to translate everything, from taxonomy to pages. Like the translation in the interface, the default language of the content can be configured flexibly.

Configuration translation

The things that come with a configuration of the website can be translated with the help of this module. These things include views, blocks, panels, field panels or the text for that matter that can be formatted and be easily translated.

New York County District Attorney’s Office website is built on this multilingual feature of Drupal. The district attorney CY Vance Jr. is the leader in the criminal justice reform who proposed a compelling vision for moving the Manhattan District Attorney's Office with the main agenda of prevention of crime. His objective of the project was to easily reach people with the continuous publication of the content that served as an information portal for the District Attorney.

Drupal was an ideal CMS as it provided with a great platform to build complex websites and was helpful in integrating interactive web services. The key agenda was to reach as many people as possible.



How Can We Forget Security?

In 2016, Panamanian law firm Mossack Fonseca faced a leak of over 2.6 terabytes of data highlighting the risk around data security and the need of companies to protect their client's information.

This clearly indicates that security plays a crucial role for all law firm websites. Visitors want assurance over their data. They want that it should be secured and private. 

Drupal is the CMS that is well known for its security. It presents its users with careful testing of all modules which is done by the Drupal experts. The password is encrypted and the community reviews the modules on go. With security modules like security review, two-factor authentication, paranoia etc, the vulnerabilities or loopholes that compromises a website, are largely taken care off. Not only this but, Drupal also meets the Open Web Application Security Project (OWASP) standards which are actively screened to prevent continuous future risks. With the selection of Drupal as your platform, your website is continuously reviewed by the Drupal Security Team. The CMS makes sure that the security vulnerability is reported to them.

Module, Themes, and Distribution 

Drupal has special modules, themes, and distributions which are specifically created for the law firms. 

The law firm creates and shares attorney profiles with potential client quite frequently. This might be a time-consuming and might also slow down the entire process as there can be a number of attorneys lined up for your firm. Thus, to improve the performance and save time for the same, Drupal comes with a module known as profile generator that allows you to find profiles quickly.

The law theme is a free professional mobile-friendly theme for the law website. It is a responsive, mobile first theme for Drupal 8. It consists of features like configurable slideshow, 13 block regions, social media integration, clean HTML5, and so on.

The law firm distribution, which is also known as pre-configured Drupal version containing the core of the entire system, is a set of modules, themes, and libraries. They make the site creation easy and swift. 

This is also a fully responsive distribution that features a homepage with a slider, a section for legal industry events, a photo gallery, a section with YouTube videos rendered in a structured way, and much more.

Give full attention to the page load time 

Having a faster page load speed isn’t only increasing your Google ranking, but it is also contributing to customer satisfaction. Faster page navigation means that users may see more page views each time they visit your law firm website.

Conducted on the behalf of Akamai, Forrester Consulting found out that, 47% of the customer expect to wait no longer than 3 seconds for a web page to load.  With the usage of specific modules and methods, Drupal manages to reach marketing goal faster. Modules and methods like:

Caching your pages

Drupal 8 is such an understanding CMS that it enables caching by default for anonymous visitors. The user has the ability to select the maximum limit of the page caching based on how quickly the content of the website changes.

Compress images (CSS and Javascript files)

Google is really fond of fast loading sites. Advanced CSS/JS Aggregation module aggregates and compresses the CSS and Javascript files to make the site run faster.

Content Distribution Network (CDN) 

The role of a CDN is to store websites on a server, and the CDN module in Drupal provides easy CDN integration to all the Drupal sites. It changes the file URLs so that the file is downloaded from a CDN instead of the server.

Google Analytics

Drupal also provides its users with web statistics tracking system called Google Analytics. The module allows the users to add statistics features like single/multi/cross domain tracking, monitoring the links that have to be tracked, monitoring the files that are downloaded, supporting site search, Drupal message tracking etc

Content is the King 

Note that if your website content does not engage the user then it might not be serving the purpose even if your website consists of great web design. Poor content tends to lose the audience. 

Drupal allows its user to edit and customize content without the need of modifying the entire website. With the help of intuitive modules like ctools, field group, paragraphs, entity API etc, the user can build their own content types that have their own set of fields. 

According to content marketing institute, 89% of B2B organizations are using content marketing as their strategy of marketing business. 

Source: Content Marketing Institute

And Drupal is the platform which lets you deliver personalized content and contributes vividly as a content manager. 

Drupal would not only contribute to the editing and deleting part of the content but it would also help you to future-proof it. Machines are able to read the content by reviewing the metadata of a website. The metadata structure which is also called as the schemes provide context to the content of a page. Which means that when the search engine views the page they are not only repeating the content but also serve with additional guidance. Drupal 8 uses Schema.org for tagging. Not only this but Drupal has also changed its migration path to provide its user with semi-annual updates which save time, money and a lot of energy 

You just can’t ignore the cost factor 

If you are choosing the best CMS for your law firm website then it should be 100% free and should have the ability where the user can easily install it without the hassle of purchasing any license or recurring fees. 

Drupal comes with the option of choosing from the variety of open source modules that can be used for developing a website adhering to your preference. 

In the Nutshell

It is evident that Drupal has become a very popular platform for lawyers and law firms, especially among related marketing professionals, and for a good reason, this powerful and versatile CMS offers exactly the right tools and visibility potential to both the existing audience as well as to the new ones. 

Opensense Labs has sound experience in building such websites and provide services that help you modify your website. It would be our honor to help you develop a dream site that would not only benefit you in every aspect but would also bring about a planned and systematic architecture for your law firm. 

Ping us on hello@opensenselabs.com. Now. 

blog banner blog image Drupal Drupal 8 Law Firm Website Legal website Drupal community Decoupled Drupal User Experience Multisite Multilingual Site Security Drupal Modules Performance Blog Type Articles Is it a good read ? On
Categories: Drupal

Create fields in Drupal 8 Profile Entity Type and attach field instances to Drupal8 node type bundle from other node Type Bundle

New Drupal Modules - 6 January 2019 - 12:14am

This module is a collection of useful drush commands for cloning/creating/copying fields in the node entity type bundle and in the profile entity type bundle of Drupal 8 from other node entity type bundle.

This module provides 2 useful commands for drupal 8 fields:--

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal