Blog /Technology

Building multifunctional websites and web applications is hardly an easy task. We support ourselves in this process with various programming languages and tools.

We are the largest and best-known company dealing with creating and supporting Drupal-based websites in Poland. Our areas of expertise also include Symfony, PHP, ReactJS and front-end development. In our endeavours, we also use a variety of other software solutions, such as PHPStorm, Jenkins and Docker.

We are happy to share our experiences, describing the process of work on building and developing websites and applications at Droptica. Thanks to SCRUM and the right tools such as Slack and Jira, we ensure seamless communication between the team and the client. We systematically improve or change the software we use in order to automate repetitive actions and speed up the development work.

You can learn more about the ins and outs of our work thanks to our extensive blog articles, or you can find out what benefits we can offer you thanks to our Case Studies.

Everyone who does Drupal development will sooner or later encounter the need to define tighter control of access to content. The standard mechanisms of roles and permissions are very flexible, but they may be insufficient in complex projects. When access to nodes starts to depend on, for example, fields assigned to a given user, then you have to take advantage of more advanced solutions.
Has it ever happened to you that when you were looking on a website, you weren’t sure whether a font you used was 12 pt or 13 pt? Or maybe you kept looking at an image, wondering whether it had been moved slightly to the left before? If the layout is a priority on your website, maybe it’s time to think about automating the testing of this aspect of your project. VisualCeption is a noteworthy solution for exactly this use case.
We do a lot of Drupal development. We also do a lot of automated testing. This is why we decided to complement the standard functionality of Codeception with some new modules dedicated to Drupal. This helps us a lot in our daily work. As in our previous article, all examples listed below will be based on a project based on docker-console, which is why we encourage everybody to read the previous articles first if you didn’t do so yet.
If you read our previous posts, you already know very well how to start a project in the docker-console. If you haven’t done it yet, you should start with this article, because for the purpose of this article we assume that your project in the docker-console is already up and running, therefore all commands executed below will refer to it. In this article, we would like to introduce you to the world of automatic tests using Codeception, based on this kind of a project.
If you are a Drupal developer, it is almost certain you have heard of drush. Drush is a commandline utility which allows you to interact with drupal, well - from command line. Every Drupal agency or any one worth his salt who does drupal development, uses drush because it masively speeds up drupal development, saving time and money.  Drush comes with many built in commands, but you can also add your own.
When creating websites, you probably sometimes saw how your page changes its appearance on different browsers, not to mention a variety of devices. Depending on how many different configurations we will want to check, the amount of time spent on testing them will grow rapidly and the enthusiasm will probably decrease at a similar rate with repeating the same action on another device.
Content creation using the Paragraphs module is a completely different approach compared to the "standard" content creation in Drupal. In short: we prepare the components (paragraph type) and then, during the creation of an entry, we select any of the available components.  The components can be simple elements containing text, contents with columns or such complex elements as sliders, videos or photo galleries.
Everyone who has ever worked in IT has surely stumbled upon communication issues between programmers and testers, or in other cases. Talking to programmers, you can hear many anecdotes regarding bug reports and feedback they have received. Working as a tester in a drupal agency, I see this issue from the other side, but I understand the developement team. When returning a task from tests, I often find myself wanting to write just: “It doesn’t work!”.
MG 1202 Blur

Need a team of Drupal and PHP web development experts?