Magic Theme module let you can full custom drupal theme output. You can control each line of code, just like the pure HTML original template. Completely separate from the front-end and back-end.
if you want to test, please enabled the sub module "Hunter Test", and use special theme: https://www.drupal.org/project/amazeui
Note: I'm not sure if there is a security risk, so ask yourself if it's used in the production environment.
Using this module you can trigger any rules action by pressing a physical button.
The project has been sponsored by netidee - powerful innovations.
This is the tenth installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.In this post we will cover...
- The context you should consider based on what type of institution you are
- Questions you should think about regarding affiliated websites run by individuals at your organization
We want to make your project a success.Let's Chat.
Depending on the type of organization for which you are writing a governance plan, you may need to address the issue of personal websites within the context of your institution’s web properties and server environment. For colleges and universities, the questions you need to answer will likely be in relation to faculty, students, and alumni. For businesses, the questions will relate to employees. For non-profits, it may be employees, trustees, and/or volunteers.
Regardless of who the people are, or what function they serve in the organization, if they have a website affiliated with your organization that they control, you probably want to have some guidance for how those properties relate to your organization. Here are some questions to consider for all types of institutions.
- Are there services available for individuals in your organization to have a personal or independent web property (i.e. website, blog, social networking account, etc.)?
- Who provides the service(s)?
- How does an individual acquire the web property?
- Who owns and maintains the web property?
- Where is the web property hosted (i.e. whose servers)?
- Who provides technical support for the web property?
- What levels of support are provided (hosting, domain, programming, training, etc.)?
- Who designs and produces the property?
- Are there guidelines related to visual appearance?
- What happens to the web property if the owner leaves the organization?
- Are there subject matter limitations or guidelines for personal sites?
- Is there any form of review process for content on personal websites?
- What happens if a personal website owner violates subject matter guidelines?
- Who is responsible for costs related to personal web properties?
- Are outside or 3rd-party vendors permitted to work on personal web properties?
- How do 3rd-party vendors access the site and deliver changes?
This list is not an exhaustive checklist for personal website governance planning, but it is a good start that should unearth further questions and circumstances to consider for your plan.
This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:
- Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
- Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
- Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
- Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
- Roles and Permissions – Define who should be able to do what in each system.
- Content – Understand how ownership and permissions should apply to content.
- Organization – Establish how the content in your digital properties should be organized and structured.
- URL Naming Conventions – Define how URL patterns should be structured in your websites.
- Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
- Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
- Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
- Web-Based Applications – Consider use and ownership of web-based tools and applications.
- E-Commerce – Determine the role of e-commerce in your website.
- Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
- Social Media – Set standards for the establishment and use of social media tools within the organization.
- Digital Communications Governance – Keep the guidelines you create updated and relevant.
Stay connected with the latest news on web strategy, design, and development.Sign up for our newsletter.
This module allows you to override configuration on a per-environment basis.Motivation
In Drupal 8, settings are managed in one of two ways.
When we last checked in with Rod Martin, in a previous post, he was touring the Drupal 8 interface. In this course, Building a Basic Site Using Drupal 8, he shifts into tutorial mode, deliberately moving step by step through the creation of a fictional Drupal 8 site, Drupalville, which he describes as a site about “all things Drupal.”Tags: acquia drupal planet
In my last article, I talked about new options for setting up a development environment in Drupal 8. Having done that, I need to setup a workflow for development as well as a process for deploying changes. Additionally, for this project, I have a partner that I need to share changes with before they go live. It would be really nice for her to be able to preview these changes and push them live after review.
As mentioned in my last article, I have a pretty basic setup for this project. I am doing work on my local laptop, and I have a private repository on Github for my code, and two virtual hosts on my hosting provider. One is a preview site that is password-protected so that we can review changes as they go live, and one is the production website.undefined
There is no custom code at all in the Pinball Outreach Project website outside the theme (and precious little there), but there is a lot of custom configuration that needs to be pushed around. Additionally, some of that configuration is tough to test outside of a site that is publicly accessible. Thankfully, Drupal 8 brings the gift of CMI.The simplest workflow
I realize I may be biased, given my role as the former CMI initiative lead, but I have to say, the D8 configuration management system is an absolute joy. It allows a variety of workflows and performs precisely as advertised. I created a pretty simple workflow for this project, but one of the beauties of the system is that you can create a workflow as simple or complex as needed.
Using the built-in Configuration Synchronization tool that ships with Drupal 8 provides the simplest possible workflow. Go to:
...and download your site's entire configuration as a tarball. You can then go to:
...on the destination site and upload that tarball into the new system. Once you have uploaded your configuration, you are presented with a list of the items that have changed and have the opportunity to review each one.undefined undefined
In this example, I have changed the view called 'Press' to sort descending instead of ascending. If you are happy with these changes, then you can click Import All to integrate them into your site.
While this doesn't give you all the functionality a more technical user might require, it works and would be sufficient for a simpler site.My workflow
I wanted to have a little more control over my configuration and maintain the ability to experiment and roll those changes back if I decided I didn't like them. My process, which is still basic as deployment workflows go, works like this:
- I make some changes through the admin UI on my local development environment.
- I open up a terminal to this environment and run drush config-export -y from the project's root directory. This exports all configuration to your config export directory (see the last article in this series for details about how that is set up.)
- Again, in terminal, I run the git status command to check that my configuration changes are what I expect them to be. If all has gone well, I should see that some configuration files have been modified in my config export directory, and this configuration should only be related to the changes I just made.
- I add the changes to git (git add), commit (git commit -m) and push them (git push).
- Next, I SSH to the destination environment and pull the changes down (git pull).
- Finally, I run drush config-import -y from the project's root on the remote server. This command imports the configuration changes I pulled down from git.
While this might seem like a pretty simple workflow, it is incredibly powerful, especially if you are used to the Features workflows prevalent in Drupal 7. First off, it allows you to be as granular as you want with your commits. I can commit a change as simple as adjusting a View's sort order or as large as an entire collection of new content types. With my changes in version control, I can roll them back as easily as I can import them (mostly, some content type/field changes cannot be rolled back.) Keeping changes as simple as possible can also help minimize merge conflicts in projects with multiple developers.undefined
This process will work between any source environment and any destination environment, assuming the two environments are instances of the same site. Clearly, it is both ideal and easy to make changes locally and push them live, but that is not always the best option. For instance, while setting up Metatag module, I realized it would be much easier to test from a publicly accessible environment. So I went to the live site and tweaked my settings to where I wanted them, then exported and committed these changes and brought the changes back down to my local. In another case, I was on the phone with my partner who was viewing some changes on the preview site. As she was making comments and asking for changes, I made them until we were both happy with them. Then, I could merge those changes down to my local before pushing them live.
In many cases, this setup will not be workable. As the sole dev and site admin, it works for me because I know exactly what is going on all the time and I can make sure that the changes I'm making won't overwrite someone else's work. Nevertheless, there's no reason this model couldn't be expanded to work with multiple developers. For instance, you could lock down the live site so that its admin is read only (simple with a module like Config Read Only) and then come up with an automated or user-instantiated process to make those changes live. This could also pretty easily be expanded to a multi-developer environment.More advanced options
Here at Lullabot we have already started talking through some different options for our more advanced projects. In one case, we ended up going back to Features. The client already had a Features-based workflow for their D7 site and was reluctant to change to a totally new system. Additionally, they maintained a network of sites based on a common core repository or “distribution.” We needed to get off the ground quickly with something we already understood rather than figuring out a config workflow that would work. Features offered us that.
Alex Pott has proposed another workflow that involves shipping your config with an install profile. In this scenario, your configuration lives in your install profile, and you essentially rebuild your entire site from scratch when you push changes. This works especially well with advanced composer-based workflows in which your assets are scattered and imported as part of your build process. Additionally, this setup can get around some technical problems involving the way Drupal 8 assigns UUIDs to configuration. For more information on this, see the presentation he did with fellow Lullabot Matthew Tift at DrupalCon New Orleans.
As we get farther and farther into the Drupal 8 cycle, we will see a ton more workflows and processes around configuration management and deployment. Some will be use-case specific, some will end up becoming best practices, and some will probably just be weird. I wouldn't have it any other way because it means the configuration management system works for site owners and not the other way around.
Next in the series, I will talk about some interesting things D8 has enabled around theming and templating.
Header photo by Karl Lind Films
At FFW, 90% of our staff spends all day, every day, working with code. We’re site builders and developers, and we’ve created a number of tools to help make our jobs easier. Today, we’re excited to share our Docksal development environment with you in the hopes that it will make your team’s life easier, too.
Docksal is an open-source tool created by FFW for defining and managing development environments. It brings together common development tools, minimizes time spent on configuration, and ensures the consistency of local development environments throughout a team’s continuous integration workflow.
Docksal automatically configures each project's environment to ensure team members are using the same tools, and versions, regardless of the individual requirements of each project. Most importantly, it makes the entire process easy. Docksal offers fully containerized environments with Docker, provides cross-platform support (MacOS, Windows, and Linux,) and has built-in tools that include:
- Drupal Console
- PHP Code Sniffer
- Apache Solr
- Built-in testing support with Behat and Selenium.
Docksal will even automatically configure virtual hosts for you, so no more editing host files and server configurations.How can Docksal help your organization?
Docksal has a threefold value proposition. It improves time-to-market and quality on development projects through:
- Bringing together common development tools on a unified platform
- Minimizing time spent configuring development environments
- Assuring quality by ensuring that local environments are consistent across a team’s continuous integration and development workflow.
Docksal makes it easy to bring new team members onto projects in no time flat: the software allows them to get set up and running easily and quickly. We built Docksal to streamline the process of adding team members to our projects: previously, they’d have to go find the code for the project, get it set up on their laptop, get it to work with everything on their laptop, perform a database dump, get the site running. We wanted to simplify this process.
Docksal reduces the work of several hours to several minutes. Our developers don’t have to waste time figuring out why the code isn’t working with the configurations they have on their computers, and our teammates who aren’t code-oriented don’t spend frustrating hours trying to simply access the project. With Docksal, anyone can get a specific Drupal environment set up and running on their machine in two minutes -- and everyone is running the same environment, which acts as an important check on quality and consistency.Our suite of development tools
Docksal’s features may sound familiar to those of you who previously used our Drude tool. That’s because Docksal is Drude renamed and expanded. Docksal doesn’t just work with Drupal: it works with WordPress, stand-alone HTML files, or any other PHP project— because even though we all love Drupal, sometimes we have to work with other technologies, too.
In addition to Docksal, we’ve also created another development tool called CIBox. CIBox (Continuous Integration toolbox) is a development workflow tool that simplifies the process of checking changes to each project’s codebase. CIBox uses continuous integration -- the process of immediately testing new code when it’s contributed to a project -- to support a truly Agile development process.
CIBox allows developers to have an unlimited number of testing environments, deployment plans, and additional automations. It supports a continuous integration server dedicated to running site builds and tests, as well as a toolbox of scripts for Code Driven Development with Drupal, Wordpress, Symfony, Sylex support. It offers deployment plans and skeletons, and an improved QA workflow from most CI tools. Stay tuned for an upcoming blogpost that speaks to CI Box in more detail.Try the software for yourself
Docksal and CIBox are both great tools for building projects and managing development environments. Both have saved us a lot of time and ensured that we have streamlined, quality-focused processes.. To get Docksal for yourself, visit docksal.io for downloads and more information, or to try CIBox, check here. We hope that you give them a try — we think they’ll make your life better, too.Comments
Provides drush commands to index fast with search API (using all your CPU cores).
It's an effective multi-process approach by spawning new drush commands that handle queues.
If you have a 100k+ node-set, this is highly useful.
Relies on drush and unix/linux-based systems.
Organizations are using Enterprise Content Management (ECM) to manage their digital content. ECM is used to manage traditional documents like: word, excel, ppt and pdfs that are created with complex workflows. ECM is popular in the Financial Services, Medical Services, Manufacturing, Government and Publishing. ECM brings with it storage, versioning, workflows and highly customizable metadata models.
We're happy to announce a new kind of series on Drupalize.Me which provides a project for you to practice the skills you've learned in Drupal site building, theming, and module development. Our free Hands-On Exercises: Movie Project provides you with wireframes and customer requirements for a movie review site. Each exercise in the series has you progressively build the site according to the specifications. To help you along the way, each lesson also lists some tutorials and learning resources that will show you what kind of knowledge you need to have to accomplish the given tasks.
Here is where we look at Drupal modules running on less than 1% of reporting sites. Office Hours allows you to easily display repeating weekly time schedules.
The Rules Login provides additional actions to the Rules module that allow your rules to log users in and out.
Today we held the last Board meeting of the year. We met virtually via Zoom and covered two important topics. The first one was a presentation by Angie Byron, who serves on the Technical Advisory Committee. She gave an update on the group’s current tooling study along with next steps, which will include a community blog post where members can provide input on the various tool options being studied.
The second item was sharing our thanks and saying goodbye to two wonderful Board members whose seats expire this month - Danese Cooper and Rob Gill. Danese, who has been on many open source foundation boards, provided great insight and knowledge that helped us navigate as we matured as a community and a Project. And Rob, who worked for NBCUniversal when he first joined the Board, was instrumental in helping The Association understand how to better serve the needs of the end users in our community. We are a better organization because of their generous donation of time and talent.
Please go here if you would like to watch the November 22 Board meeting, read the meeting minutes, or review the Board packet, which also includes our 12 month execution plan dashboard.
We will announce the 2017 Board meeting schedule next month.
Now that Drupal 8 is one year old, you may be asking yourself: “What am I waiting for?” In the last year, thousands of Drupal 8 sites have launched, including NBA.com, Nasdaq Corporate Relations, and Jack Daniels. If you haven’t started your own personal, professional Drupal 8 upgrade, here’s a good reason to get going: the availability of excellent free Drupal 8 learning resources.Tags: acquia drupal planet
Acquia Developer Center Blog: Contribution Stories: Bassam Ismail, React front-end for your Drupal 8 back-end
Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Our community becomes better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to Drupal. Acquia is proud to play a part, alongside thousands of others, in some of the stories making tomorrow’s Drupal better than today’s. One of them Bassam Ismail’s.Tags: acquia drupal planet
At Drupalcamp Atlanta 2016, my Partner (Paul Chason) and I were humbled to have an opportunity to deliver the keynote address at Kennesaw State University. The topic we discussed was “Creating a Culture of Giving in Your Organization.” As we started to conduct research, there were four key questions we wanted to address:
This is the sixth post in a series about coding standards. In this post we’ll talk about how to adhere to standards when writing object-oriented code in Drupal.