DEV Community: visuellverstehen

Access Current Entry in Custom Validation Rule

Julia Lange — Fri, 22 Dec 2023 08:57:01 +0000

Sometimes, when writing a custom validation rule for a Statamic project, I find myself in a position where I need information about the current entry I am editing.

But because validation rules don’t provide this kind of information, I've tried some hacky stuff like reading the current entry id from the request URL. However that doesn't work if you have more than two stacks open at once.

Luckily I discovered that Statamic did a nifty thing with their own validation rules. Just like unique_entry_value, unique_term_value & unique_user_value you can pass the current id, collection and the site like this to your validation rule:

resources/blueprints/collections/pages/default.yaml

validate:
   - 'custom_validation_rule:{id},{collection},{site}'

Those values can then be found in the parameters array inside the validate method.

App/Validation/CustomValidationRule.php

class CustomValidationRule
{

   public function validate($handle, $value, $parameters, $validator)
   {
      $id = $parameters[0];
      $collection = $parameters[1];
      $site = $parameters[2];

      // Do stuff with it.
   }
}

That's all there is to it. Simple, but powerful. Happy coding, everyone!

Create an entry approval workflow with Statamic Revisions

Lakkes — Thu, 14 Sep 2023 09:14:38 +0000

When managing entries in your Statamic application that gather external data, such as from APIs, you may find it necessary to implement a data control step before publication. Statamic offers a useful tool for this purpose known as the revisions feature, specifically focusing on working copies.

In the following sections, I'll guide you through the process of creating an Approval Mechanism for Statamic.

This article is structured as follows:

Who is this article for?
What we are about to do
Let's bring in the data!
Let authors know that there's something to review
Create a feedback form
Tracking feedback and dates
Handling publication
Conclusion

Who is this article for?

This article is primarily aimed at Statamic developers who are already acquainted with Statamic's core concepts and have a basic understanding of PHP and Laravel. To fully comprehend and implement the Approval Mechanism discussed here, readers should be familiar with key Statamic elements like entries and blueprints.

Additionally, a basic grasp of Vue.js for handling user interface components and API integration knowledge will prove beneficial in following concepts presented in this article.

I would recommended that you also have a basic understanding of extending Statamic, but if you're new to this, it's a good idea to explore those concepts beforehand for a smoother learning experience.

You need Statamic Pro to enable the revisions feature.

What we are about to do

In this article, our primary objective is to create an Approval Mechanism within Statamic, emphasizing the process of managing entries and enabling a structured review and feedback workflow. While we briefly touch on data import as context, our main focus lies in developing this mechanism. We'll explore how to efficiently flag entries as 'Needs Review,' facilitate feedback from CMS authors through a built-in feedback form, and dynamically update entry statuses for better organization.

Additionally, we'll demonstrate how to log feedback and maintain feedback history as part of this comprehensive solution. For illustration, we'll use a 'persons' collection where each person is associated with a unique 'external_service_id,' linking them to external data sources.

What's a working copy?

Working copies serve as a temporary version of an entry, generated when you edit and save an existing entry. You then have the option to create a revision or proceed with publication. Should you opt for a revision or publication, the working copy will be discarded. Conversely, choosing to save your changes ensures that the working copy is promptly updated.

By default working copies are saved inside the revisions folder. The path can be set in the config/statamic/revisions.php file. By default it's set to storage_path('statamic/revisions').

Let's bring in the data!

We assume we already have some existing persons in our collection. Inside our import method we want to update or create a working copy of each entry.

foreach ($personEntries as $personEntry) {
    if ($personEntry->hasWorkingCopy()) {
        // Update working copy
    else {
        // Create working copy
    }
}

Now let's implement these methods. We are assuming that the new data comes in an array that represents the data structure of our person blueprint. For example:

$newData = [
    'name' => 'Smeagol',
    'diet' => 'juicy sweet fish',
    'job_title' => 'Tourist Guide',
];

Creating the working copy

function createWorkingCopy(Entry $entry, array $data)
{
    // Set the new data
    foreach ($data as $key => $value) {
        $entry->set($key, $value);
    }

    // Create a working copy from the entry
    $workingCopy = $entry->makeWorkingCopy();

    // Save the working copy
    $workingCopy->save();
}

Updating the working copy is a little more complicated since the data can't be set directly on the working copy. We have to get the data from the working copy, update it and then save it again.

function updateWorkingCopy(Entry $entry, array $newData)
{
    // Get current data from the data attribute and merge it with the new data.
    $currentData = $entry->workingCopy()->attribute('data');
    $updatedData = [...$currentData, ...$newPureData];

    $entry
        ->workingCopy()
        ->attribute('data', $updatedData)
        ->save();
}

So, at the moment, we always create or update a working copy and overwrite a possible existing one. In this case, that's okay, but you may want to check if there is already a working copy, and if so, create a new revision instead of overwriting the working copy. But that results in potentially a lot of revisions. So you have to decide what's best for you. I will only cover the working copy case here.

Additionally, you should have a field in your entries blueprint where you save the last imported date to check if the incoming data is newer than the last import. If not, you can skip the entry. That, of course, presupposes that your external data also provides some kind of 'updated_at' field.

Let authors know that there's something to review

What we did before is basically everything you need to have a simple approval mechanism where new data gets saved inside a working copy to be reviewed. But we want to give the CMS authors a hint that there is something to review. We will do this by adding a status field.

What we need is a custom field type that we can use in our blueprint. I won't go into detail here about how to create a custom field type. You can read about it in the Statamic documentation.

We will create a custom field type called 'approval_status' that will have three possible values: 'needs_review,' 'approved,' and 'feedback_sent.'

We will add some methods to our ApprovalStatus.php fieldtype class to check the status.

public function preProcessIndex($data)
{
    return $this->getStatus();
}

public function preload()
{
    return $this->getStatus();
}

protected function getStatus(): array
{
    $entry = $this->field()->parent();

    return ApprovalStatus::get($entry);
}

As you can see, it can be better to outsource the logic to a separate class. We will create an ApprovalStatus class that will have a static method to get the status. This method will use a variable $feedbackDate. This variable will be set when the CMS author gives feedback and deleted when the working copy is published. We will cover this later.

Here's a little diagram that visually explains the logic behind the status check:

… and the corresponding code:

public static function get(Entry $entry): array
{
    $workingCopyData = $entry->workingCopy()?->attribute('data');
    $feedbackDate = $workingCopyData['feedback_date'];

    // The person has no working copy and is published, so there's noting to be reviewed.
    if (! $entry->hasWorkingCopy() && $entry->published()) {
        return ['status' => 'approved'];
    }

    // The person has a working copy and has no feedback date, so a review was sent.
    if ($entry->hasWorkingCopy() && $feedbackDate) {
        return ['status' => 'feedback_sent'];
    }

    // The person has a working copy and has no feedback date, so it needs a review.
    if ($entry->hasWorkingCopy() && ! $feedbackDate) {
        return ['status' => 'needs_review'];
    }
}

The Vue components to our ApprovalStatus field type class are pretty simple. They get the status with the help of the preload() and the preProcessIndex() methods.

// ApprovalStatus.vue

<template>
    <div>{{ this.meta.status }}</div>
</template>

// ApprovalStatusIndex.vue

<template>
    <span>{{ this.value.status }}</span>
</template>

You can also add your classes and pass a color to your status array to style the status in the control panel. You can find more information about index field types here: Statamic Index Fieldtypes

Giving Feedback

Create a feedback form

The form is also a custom fieldtype. It will have a textarea and a button to submit the feedback. We assume that the person entry has an email stored. We can write our feedback into the text field and with the click on the button, we will make a post request to a custom route that takes care of error handling and sending the mail. After sending the mail, we want to disable the form and the button to prevent multiple feedbacks.

This is how the Vue component can look like:

<template>
    <div>
        <textarea v-model="message"></textarea>
        <div>
            <div>Send a mail to {{ this.mail }}</div>
            <button :disabled="mailSent" @click="sendEmail">
                <span v-if="this.mailSent">E-Mail is on the way</span>
                <span v-else>Send E-Mail</span>
            </button>
        </div>
    </div>
</template>

<script>
import axios from 'axios';

export default {
    mixins: [Fieldtype],
    inject: ['storeName'],

    data() {
        return {
            message: '',
            mailSent: false,
        };
    },

    computed: {
        mail: function () {
            return this.$store.state.publish[this.storeName].values.email;
        },
        pid: function () {
            return this.$store.state.publish[this.storeName].values.pid;
        },
    },

    methods: {
        sendEmail() {
            this.$progress.start('review_mail');

            axios.post('/admin/person/review/send', {
                message: this.message,
                email: this.mail,
            })
                .then(response => {
                    this.$progress.complete('review_mail');
                    this.$toast.success(`E-Mail sent to ${this.mail}!`);
                    this.mailSent = true;
                })
                .catch(error => {
                    this.$progress.complete('review_mail');
                    this.$toast.error(error.response.data.error);
                    this.mailSent = false;
                });
        }
    }
};
</script>

Tracking feedback and dates

To allow a better overview of previous sent feedback, you can log your feedback in a replicator field below the feedback form. Simply add some code to the method that handles your post request from the form component above. Let's assume this method is inside the same class as the create and update working copy methods.

function saveFeedback(string $entryId, string $feedbackMessage)
{
    $entry = Entry::find($entryId);

    $currentFeedbackLog = $entry->workingCopy()->attribute('data')['feedback_logs'] ?? [];
    $newLog = [
        'type' => 'log',
        'enabled' => true,
        'id' => RowId::generate(),
        'mail' => $feedbackLog,
        'time' => now()->format('d.m.Y H:i:s'),
    ];

    $updatedLog = array_merge([$newLog], $currentFeedbackLog);

    $this->updateWorkingCopy($entry, [
        'feedback_logs' => $updatedLog,
        'feedback_date' => now()->format('Y-m-d\TH:i:s.uP'),

    ]);
}

Handling publication

To finish up the approval mechanism, we just have to delete the feedback date automatically when the entry gets published. We can achieve this by listening to the EntrySaved vent. We will create a listener class that will check if the entry is from the persons collection and has set a feedback date and if so, delete the feedback date.

public function handle(object $event): void
{
    $entry = $event->entry;
    $collectionHandle = $entry->collection->handle;

    if (! $collectionHandle === 'persons') {
        return;
    }

    if (! $entry->feedback_date) {
        return;
    }

    $entry->set('feedback_date', null)->saveQuietly();
}

This is how the Feedback UI could look like:

Conclusion

Great! 🎉 We now have a simple approval mechanism for our Statamic application. Of course, you can extend this mechanism to your needs. For example, you can add a field to your entries blueprint where you can set the email address of the person that should review the entry or for the person that should review it. It's also very handy to add a filter to your index view to filter for entries that need a review.

When handling multisites, you should think about if you want to have a separate approval mechanism for each site or if you want to have a global one. In my case, I disabled the review form for any other language than the default one, and the authors are always sending reviews for all localizations in one mail. When creating and updating the working copy, you have to update each localization separately. Take a look at the $entry->descendants() method to get all localizations of an entry.

I hope this article was helpful for you. If you have any questions or suggestions, please let me know in the comments. 👋

Effortless Language Redirection - TYPO3 Extension

Yamen Hadla — Thu, 23 Mar 2023 08:27:09 +0000

Introduction

Hello fellow TYPO3 enthusiasts! I had the pleasure of cooperating with my colleague @malteriechmann to create a TYPO3 extension called t3languageredirection, which provides an effortless and dependable way to redirect users to their preferred language. In this blog post, we will take a look at this simple project, and reveal how it can add user-friendliness to your multilingual website.

What does `t3languageredirection` actually do?

This open-source extension, will configure a new frontend middleware that automatically redirects users to the appropriate language version of your website based on their browser's Accept-Language header.

The LanguageRedirectionMiddleware is implemented using the PSR-15 middleware interface, making it easy to integrate into your existing TYPO3 project.

Why `t3languageredirection`?

Unlike other TYPO3 redirection extensions, t3languageredirection does not require any additional configuration and is not dependent on the user's IP address. Additionally, it is designed to be independent of the underlying web servers, providing a flexible and adaptable solution.

Using t3languageredirection will improve the user experience of a website and make it more accessible to a wider audience. Whether your website is a small blog or a large e-commerce site, this extension is a nice-to-have tool for anyone looking to create a multilingual TYPO3 website.

How to use `t3languageredirection`?

To get started, simply install the extension using Composer:

composer require visuellverstehen/t3languageredirection

After installation the middleware will automatically handle language redirection. This means that visitors to your site will be redirected to the language version that best suits their needs without any additional effort on your part.

Conclusion

The t3languageredirection extension simplifies the language redirection of your multilingual website with easy installation, automatic redirection, and seamless compatibility with any hosting environment. The extension is still in the testing phase, and we are constantly working to refine and improve its functionality.

Feel free to utilise it or to give us feedbacks, and if you could star the repository, we would appreciate it:

https://github.com/visuellverstehen/t3languageredirection

Accessible website: 7 steps to better accessibility and SEO performance

Dorien Grönwald — Thu, 12 Jan 2023 13:20:17 +0000

Web accessibility enables people with physical and/or mental disabilities to use the Internet with as few barriers as possible. But to make a website accessible, many different factors must be taken into account.

However, there are a few small adjusting screws that not only make a website more inclusive, but also serve search engine optimization (SEO).

7 steps you shall take

The following points have a positive effect on digital accessibility and at the same time can lead to a better ranking of the website, which in turn ideally expands the target group and increases the site's traffic. A real win-win situation.

1. Clean structure of the website

A clean HTML structure and proper semantics are the foundation for a well-performing and inclusive website. This is because if a site is structured in a sensible way, search engines can easily understand what kind of information and content is present and how it needs to be processed.

However, this doesn't just apply to search engine crawlers - programs that crawl and index websites. Assistive technologies such as screen readers, which read the content of websites aloud to users with visual impairments, also depend on websites being well structured. For example, the better the content is presented, the easier it is for the screen reader to distinguish between a list and normal continuous text.

2. Clearly formulated headings in the correct order

Structure and semantics should also be taken into account for headings. Because mistakes often happen here - although from a technical point of view only two rules need to be followed:

Only one H1 must and may be defined on a page.
All headings must be placed in the correct order. For example, an H2 may not be followed by an H4 without an H3 also having been defined first.

The search engine tries to create a factual context from the headings and the subordinate content to which the page can be ranked - i.e. placed in the search results of a search engine.

Headings as a navigation aid
The meaning of headings for assistive technologies is somewhat different. For example, users can navigate back and forth between headings and thus jump directly to specific content on a website. Here, too, headings that are valuable in terms of content and correctly labeled in terms of hierarchy are desirable.

3. Correct labeling of links and buttons

Both from an SEO point of view and with regard to web accessibility, a lot can be optimized using buttons and links. The following list summarizes the most important points:

Correct distinction between a button (<button>) and a link (<a>)
Link and button texts with valuable content
Links and buttons should be clickable and also imply this visually
Visual highlighting when navigating through the page with "Tab"
Links and buttons should have an aria-label or a title

4. Loading speed

As soon as a website takes too long to load, visitors bounce and this is reflected negatively in the SEO ranking. The most important factors for a fast loading speed are, among others, good caching and the correct dimensioning of images in modern formats. Furthermore, no unnecessary scripts or CSS files should be loaded that are not needed on the page.

Best Practice
Furthermore, it is recommended that the server should use the http/2 protocol. This can be easily tested at: https://http2.pro/

5. Images and SVGs

Optimizing images is not only an important issue regarding loading speed and SEO, but also for the accessibility of a website. For example, images and SVGs should be optimized for people with impaired vision so as not to present a barrier.

When words say what pictures cannot
Probably the most important tools for this are the alt attribute for images and the title tag for SVGs. A short description is stored there. This not only helps users with screen readers to understand what is being displayed. Search engines can also understand the context more easily and better classify the displayed content.

Purely decorative images and SVGs can and should be hidden from the screen reader with aria attributes, as they do not provide any added value.

6. Sitemap

This point is also important for SEO as well as for accessibility. The sitemap can help search engines to index all existing pages. Only then can a page be found in Google search.

Simple overview
In addition to indexing, the sitemap helps users with disabilities get an overview of all pages and navigate back and forth between them. This way, no one has to fight their way through complex navigation structures with the keyboard.

7. Page title

The page title is set by the meta title and defines which title will be displayed in Google search as well as at the top of the tab.

As an official ranking factor, a meaningful title is not only essential for search engine optimization, but also for the orientation of screen reader users. This allows them to quickly distinguish between open tabs and select the page they are looking for.

More accessibility and SEO performance for your website

Would you like to know where your website still has potential for improvement in the area of SEO or do you have questions on the subject of web accessibility?

New git guidelines: We have switched to Conventional Commits

Malte Riechmann — Sat, 22 Oct 2022 08:28:39 +0000

Giving teams as much autonomy as possible is a good idea, but having some company-wide guidelines can also help. Those guidelines will help you when people switch teams, work on multiple products, or train new colleagues.

Discuss, decide, repeat

We recently discussed some technology-related topics with all software developers at visuellverstehen. One of the outcomes of this discussion is new git guidelines. After a short debate, we have officially switched to Conventional Commits.

It is fun to see all the latest commits following a new syntax. I am curious about what we will say about this change in six or twelve months. For sure we will discuss and decide again – for the better.

New git guidelines

Below you can find the November 2022 edition of our git guidelines.

Repositories

Repositories should be named like this: vvcode-name_of_project

Branches

The main branch should be named main
The people working on a product decide if they want to work with further branches
If you need further branches, it is advisable, to add the number of the issue and a short title inside of a branch name, e. g.:
- 100-validation-errors
- 101-basic-search
- 102-german-translation
- 103-live-deployment
- 104-url-formatting

Commits

We use the syntax from Conventional Commits
Commit messages include one of the following prefixes:
- fix: to fix bugs
- feat: to introduce new features
- chore: to make general changes
- ci: to work on continuous integration/continuous deployment
- refactor: to improve existing source code
Commit messages should be written in the present form
Commit messages should be written in English
Commit messages should start with a lowercase character
It is advisable to add the issue number to a commit message
Practical examples of commit messages:
- fix: display validation errors properly, refs #100
- feat: implement basic search, refs #101
- chore: add correct german translation, refs #102
- ci: repair live deployment, refs #103
- refactor: unify URL formatting, refs #104
If a commit is a work in progress, it should be marked as such:
- fix: display validation errors properly (WIP), refs #100
- feat: implement basic search (WIP), refs #101
- chore: add correct german translation (WIP), refs #102
- ci: repair live deployment (WIP), refs #103
- refactor: unify URL formatting (WIP), refs #104

One year of coding – recommendations for beginners from a beginner

Cleo Pelte — Wed, 03 Aug 2022 07:54:00 +0000

This month one year ago I started my three year long journey as a web development trainee/apprentice at visuellverstehen. I thought this would be a good opportunity to take stock and write about the most valuable lessons that I’ve learned so far ~~and try to overcome my fear of writing~~. Since the first year of my apprenticeship was mainly about learning the basics of front-end development, this article focuses on this specific area. Most of this is old (but gold news) but I still hope that some of my fellow beginners might find my post useful. I think especially developers who are self-taught might profit from these tips. I’m also curious to hear from other apprentices and beginners as well as the grannies what they found to be valuable during their coding journey. So please share your thoughts!
But enough for the intro. Let’s start:

Know the basics

Knowing HTML, CSS and JavaScript really well is important for building a robust and clean website. The goal should always be to never channel the power of the duck. What also helps is to know how the web works. I am in the luxurious position to attend school twice a year for six weeks learning everything from hardware over networking to programming paradigms – it really changes the way you think about coding. And even before I went to school my instructor stressed the importance of knowing the basics. It seems a little bit too much for some, - you still just want to code, right ? - but it really helps in the long run. It helps with getting a general idea of what exactly you are doing, it helps with making more informed decisions, working with clients IT departments and of course with backend matters in general.

For people who are new to computer science, there is a crash course series providing a good overview of all the topics but you should definitely look further into them along the way.
Also if you don’t know how to use the terminal yet, use it! It’s so much fun and you can spare your computer from useless user interface waste.

Learn about coding principles

I love myself a SOLID DRY KISS. These are acronyms for some of the coding principles. Coding principles help you to follow some kind of guideline, instead of coding ahead with no structure. You don’t have to follow them religiously, sometimes you have to weigh them against each other but either way they help you sensitize yourself for writing (c)lean, understandable and code that’s easy to maintain.

Start with proper HTML

For every project I begin with laying down the structure of a project using plain HTML, not thinking about design and certainly no divs! Just semantic HTML. It requires a deeper engagement with a project's content to find the right HTML-tags(need help with section vs. article?) and you can easily validate your HTML after this step, which you should always do. But why should you really care about a good and solid semantic structure, when you could just mix and match and div it all away? First of all it might happen that the whole internet laughs at you. Secondly, semantic HTML helps with SEO. Thirdly, some HTML-Tags come with built-in functionalities like button or dialog, which you would otherwise have to add in later with JavaScripts, adding unnecessary loading time to your project as well as making your code more prone to errors. And last but not least, because …

Accessibility matters

Visually impaired users use assistive technology to navigate a webpage. Semantic HTML provides further information about the written content to these screen readers, that are conveyed visually for sighted users. For example is the written text a link, a button or part of a list?
When I delved into the topic of accessibility, I was surprised how unaccessible the web still is. It’s weird, considering that I (an abled user) spend up to 12 hours a day on the internet communicating, shopping, socializing, getting information, planning and working. 5 billion people around the world have a disability and most of us who are abled, will develop some form of disability in their lifetime due to illness, accidents and age.
I know diving into the topic can be overwhelming at first – I am still trying to figure out most basics myself – but if you start early and sensitize yourself for this topic you’ll save time in the long run. I emphasize this aspect because when you talk about accessibility, there is always the question of: who pays for it? But if applying accessible ways to provide content becomes a habit, it will take less and less time. Also accessibility should never be thought of as an add-on, I think it’s more a question of: is your page generally usable or not? I would suggest adding an accessibility step after every main step of the project: HTML, accessibility, CSS, accessibility, JavaScript, accessibility...

If you want to know more about this topic, I'd suggest watching this video about accessibility by Sara Soueidan, for more details on how to apply concrete measures in every front-end step, read the »accessibility in mind« series by Manuel Matuzović. I promise, you’ll know all of the important community members and their a11y content in no-time.

Structure your CSS

After I lay down the HTML foundation and add accessibility, I give away classnames. I use the BEM method to give my code structure, make it reusable and understandable for other devs. Only after this step, I start styling and finally adding the divs I need to translate the design.
I’m still unsure about CSS in many situations. That may be because programming languages feel much more structured. The answers on CSS issues I run into are often semi-satisfying or even confusing. But CSS has become much more structured in recent years with grid, flex, CSS variables and functions like clamp(), min() and max() etc. So I’d recommend learning how to use them consciously (there are even fun ways to learn grid and flex-box and CSS selectors. Here is a good talk about CSS functions).
Furthermore, applying the concepts of DRY and KISS helps your code to stay clean, readable, understandable and maintainable. For example, reduce to a maximum of 4 font-sizes to use throughout a project, even when the design might use more. Regarding larger widths, heights and spacing ask yourself: Why did you choose this sizing? Round up, round down. Did you match it by eye? If you did, try to refactor to get a clear understanding why you chose a certain sizing, or ask your designer for changes, e. g. the proportions of a SVG.

Fin.

That’s about it for now. I hope this was useful to some of you. I have yet to learn to apply them better myself and as I said, I’d love to hear from fellow developers what they find most valuable. The bottom line for me is: Structure and intention are so important to create a good product.
Lastly I have to say it was a year of ups and downs, but there were mostly ups thanks to my amazing instructor, my supportive colleagues and my lovely classmates. There is so much more to learn and I’m so excited for what is to come.

Our tech stack in 2022

Malte Riechmann — Fri, 25 Mar 2022 17:25:37 +0000

Preface

Reading about our tech stack from one year ago gives me confidence for the future. Most of the languages and frameworks are still the same as twelve months ago. I think it is good we are not switching technology that often. It means we can maintain everything for a long time and get a lot of experience in our day-to-day tools.

Of course, we also have to keep an eye on the new stuff in web development and make some innovation happen at visuellverstehen. Therefore we try out new things in real-life projects from time to time. For example, I am happy there is Meilisearch now in our tech stack of 2022.

As always, I recommend not rushing into the last NewShinyFramework™.

Clarification

This will not cover every technology in all of our projects, because individual projects do need individual solutions. But it will cover all the basics.
Legacy projects might use outdated technologies and those will not be part of this. Of course, we always try to update legacy projects.
It is not easy to categorize every technology. Therefore the categorization might not always be 100 % correct.
Not every one of us is working with all of the technologies mentioned below. Our team is organized into smaller sub-teams, which then focus on different projects.

Our tech stack

Core products

Individual digital products using Laravel and Vue.js
Content management products using Statamic and TYPO3

What people call »Backend«

Extbase
Laravel
Laravel Nova
Meilisearch
MySQL
PHP
PHPUnit
Statamic
TYPO3

What people call »Frontend«

Alpine.js
Antlers
BEM
Babel
Blade
CSS
Fluid
HTML
JavaScript
Laravel Livewire
Sass
Tailwind CSS
Vue.js
gulp.js
npm
webpack

What people call »DevOps«

Docker
Docker Compose
Git
GitHub
GitHub Actions
GitLab
GitLab CI
Hetzner Cloud
Laravel Forge
Mittwald

Honorable mentions

Three things are worth a special mention.

Although Shopware 6 is a well-crafted software, we decided against it. We want to focus on individual digital products using Laravel and Vue.js plus content management using Statamic and TYPO3. We will still maintain running client projects and support our Shopware plugins though.
One of our clients asked for Alpine.js in combination with Laravel Livewire. It turns out those work well together. Let us see if we want to use it more often in the future.
We are using Meilisearch for advanced search technologies more and more. It is a simple alternative to Solr and Elasticsearch written in Rust. It works smoothly with Laravel and Statamic. We also developed a TYPO3 extension for Meilisearch.

Happy coding

I am curious how this will change in the next twelve months. Well, we will find out. See you next year. Happy coding.

How to add pagination to your custom relationship fieldtype in Statamic

Julia Lange — Wed, 23 Feb 2022 18:54:27 +0000

Usually when building a custom relationship fieldtype you want to work with data from somewhere else than Statamic.

In this example we extended the relationship fieldtype in order to provide a list of imported tags. Thanks to the Statamic docs, this is pretty easy.



class Tags extends Relationship
{
    protected array | string $tags;

    // Fetch tags from api. 
    // Using a facade makes it nice to read and easier to test.
    public function __construct()
    {
        $this->tags = Api::tags();
    }


    // Define columns.
    protected function getColumns()
    {
        return [
            Column::make('title'),
        ];
    }

    // Take search requests into account. 
    // Just comparing strings. Nothing fancy.
    public function getIndexItems($request)
    {
        return collect($this->tags)
          ->filter(function ($tag) use ($request) {
            if (! $request->search) {
                return true;
            }

            return Str::contains($tag['title'], $request->search);
        });
    }
}

In many cases this would already be it. But what if you have a huge amount of tags or items that need to be loaded into Statamics selector stack?
I found that loading about 16000 tags at once into the selector stack would either cause unbearable loading times or even make the browser freeze.

This issue could be solved by enabling pagination. But unfortunately the relationship fieldtype does not automatically enable pagination when loading a specific number of items.

In order to do so and show pagination at the bottom of the selector stack you need to return an instance of the \Statamic\Extensions\Pagination\LengthAwarePaginator instead of a collection in the getIndexItems method.

This could be done like this:



public function getIndexItems($request)
    {
        $tags = collect($this->tags)->filter(function ($tag) use ($request) {
            if (! $request->search) {
                return true;
            }

            return Str::contains($tag['title'], $request->search);
        });

        return $this->paginate($tags);
    }


    protected function paginate($tags): LengthAwarePaginator
    {
        $currentPage = Paginator::resolveCurrentPage();
        $perPage = 50;
        $total = $tags->count();
        $result = $total ? $tags->forPage($currentPage, $perPage) : collect();

        return new LengthAwarePaginator($result, $total, $perPage, $currentPage, []);
    }

Curios about the LengthAwarePaginator? Read more in the Laravel Docs

Et voilà - a custom relationship fieldtype with added pagination:

Common mistakes when writing CSS with BEM

Malte Riechmann — Fri, 22 Oct 2021 08:48:47 +0000

Software development is a team effort

When doing software development it is essential to agree on guidelines, technology, and methodologies. Those agreements should be the result of discussions, proof of concepts, knowledge, and sometimes votes. The whole team should be invited to participate because software development is a team effort and everyone likes engaging team members.

At visuellverstehen, we are divided into multiple teams. Some teams agreed on using Block-Element-Modifier (BEM) and other teams agreed on using Tailwind CSS. I think it is super important to agree on one way or the other, while both ways are totally fine for the success of our client projects.

One thing is for sure. If you do not agree, it will become a mess. I have been there.

Learn proper BEM

Now and then new colleagues join our team. Some of them never have heard about BEM before. So they have to learn it and naturally some mistakes will happen. Mistakes are not a problem at all. They are part of the learning process.

Four most common mistakes

To help you learn proper BEM, I wrote down some of the most common mistakes I see in my day-to-day work life.

1. Wrongly nested blocks and elements

It is not allowed to nest blocks. If you start a new block, you are not allowed to proceed with elements from another block.

❌ Wrong

<article class="card">
    <header class="header">
        <h2 class="card__headline"></h2>
    </header>
</article>

✅ Correct

<article class="card">
    <header class="card__header">
        <h2 class="card__headline"></h2>
    </header>
</article>

2. Great-grandchildren

There are no grandchildren nor great-grandchildren in BEM. Instead, »normal« elements of the block can be used.

❌ Wrong

<article class="card">
    <header class="card__header">
        <h2 class="card__header__headline"></h2>
    </header>
</article>

✅ Correct

<article class="card">
    <header class="card__header">
        <h2 class="card__headline"></h2>
    </header>
</article>

3. Modifiers without a base class

Modifiers cannot exist without a base block or element.

❌ Wrong

<article class="card--highlight">
    <header class="card__header"></header>
</article>

✅ Correct

<article class="card card--highlight">
    <header class="card__header"></header>
</article>

❌ Wrong

<article class="card">
    <header class="card__header--important"></header>
</article>

✅ Correct

<article class="card">
    <header class="card__header card__header--important"></header>
</article>

4. Too big blocks

It is not a good idea to create really big blocks. The idea of BEM is to create modular and reusable blocks.

❌ Wrong

<body class="body">
    <header class="body__header"></header>
    <main class="body__main"></main>
    <footer class="body__footer"></footer>
</body>

✅ Correct

<body class="body">
    <header class="header"></header>
    <main class="main"></main>
    <footer class="footer"></footer>
</body>

Automate stuff

Sometimes it is hard to find mistakes manually. Yesterday I learned there is a BEM linter. I will look into it.

A little Slack app to ask our team social questions

Malte Riechmann — Thu, 10 Jun 2021 09:10:46 +0000

Changes coming from the pandemic

A lot has changed since the pandemic started and we all can learn a lot from the past 18 months. Because of COVID-19, we are now a remote workplace. Which is very nice, but also brings some challenges.

For example, some people from our team have never met in person. While working remotely, you do not occasionally run into someone and have to talk to him*her. The social talk decreased a lot. While it is okay for some, others want it back. How can we counteract this?

A little idea

We do not want to bring the office back and we do not want to add a lot of distraction. We just want to get to know each other a bit better. So we developed an app, which asks our team a social question every Monday at 1 pm. Those questions are posted to an off-topic channel, which is optional for everyone to read.

Questions to ask

We gathered questions and put those into a JSON file. Sorry for using German here, but those are some real questions our team was asked in the last months.

[
    ":palm_tree: An welchem Ort machst du am liebsten Urlaub? Vielleicht kannst du ja auch ein Foto teilen.",
    ":tv: Was ist deine Lieblingsserie? Und wo können die anderen diese Serie gucken?",
    ":green_salad: Welches Essen ist so gar nichts für dich?",
    ":musical_note: Welche Musik hörst du, wenn du einfach nur abschalten willst?",
    ":frame_with_picture: Wie hast du als Kind ausgesehen?",
    ":moneybag: Was meinst du? Wird Bitcoin die Währung der Zukunft?",
    ":children_crossing: Was ist deine schlimmste Jugendsünde?",
    ":movie_camera: Was ist dein Lieblingskinderfilm?",
    ":tropical_drink: Zitronen- oder Pfirsich-Eistee?",
    ":desert_island: Welche drei Dinge würdest du mit auf eine einsame Insel nehmen?",
    ":bread: Der, die oder das Nutella?",
    ":icecream: Was ist deine Lieblingseissorte und warum?",
    "[…]"
]

Source code

The app is just a PHP script, which is run by a cronjob once a week. It works like this:

Get a question from questions.json.
Post the question using the chat.postMessage API endpoint.
Add the question to questions-archive.json.
Remove the question from questions.json.

#!/usr/local/bin/php
<?php

// Abort, if not in CLI mode
if (php_sapi_name() !== 'cli') {
  echo 'Not in CLI mode';
  echo "\n";
  die();
}

// Prepare some variables
$archivedQuestionsFilename = 'questions-archive.json';
$questionsFilename = 'questions.json';

// Read questions from file
$questions = json_decode(file_get_contents($questionsFilename));

// Abort, if no questions are left
if (count($questions) === 0) {
  echo 'No questions left in ' . $questionsFilename;
  echo "\n";
  die();
}

// Send question via cURL to Slack
$curlHandle = curl_init();
$sendQuestionUrl = 'https://slack.com/api/chat.postMessage';
$sendQuestionParameters = [
  'channel' => 'C03C9RPDF',
  'text' => 'Hallo Freund*innen der gepflegten Unterhaltung.

' . $questions[0],
];
$sendQuestionBearerToken = '0123456789ABCDEF';

curl_setopt($curlHandle, CURLOPT_HTTPHEADER, ['Content-Type: application/json' , 'Authorization: Bearer ' . $sendQuestionBearerToken]);
curl_setopt($curlHandle, CURLOPT_URL, $sendQuestionUrl);
curl_setopt($curlHandle, CURLOPT_POST, 1);
curl_setopt($curlHandle, CURLOPT_POSTFIELDS, json_encode($sendQuestionParameters));
curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
$sendQuestionResponse = curl_exec($curlHandle);
curl_close ($curlHandle);

// Read archived questions from file
$archivedQuestions = json_decode(file_get_contents($archivedQuestionsFilename));

// Add question to archived questions
$archivedQuestions[] = $questions[0];

// Remove question from questions
unset($questions[0]);

// Persist archived questions
file_put_contents($archivedQuestionsFilename, json_encode(array_values($archivedQuestions)));

// Persist questions
file_put_contents($questionsFilename, json_encode(array_values($questions)));

This article has 61 positive reactions and 24 comments

Malte Riechmann — Fri, 04 Jun 2021 07:43:51 +0000

TL;DR

Using the DEV API the title of this article gets automatically updated every 60 seconds.

Addicted to numbers

I started blogging on DEV only some months ago. You could say, I am quite new to all of this. After writing an article I find myself frequently checking the numbers of reactions and comments. It seems like I am a bit of an addict. And I bet some of you are too.

We share an addiction. We're approval junkies.

— Jake Green, Revolver

It is not why I started this and I am sure it is not healthy. So I will try to stop and instead make this a bit of fun. Let's play around with the numbers.

APIs are the future

Back in 2010, I saw a tweet from Smashing Magazine asking about the future of the web. And I answered »APIs«, which is the same answer I would give today — 11 years later.

Let's have fun

It is so much fun working with well-implemented APIs and I was happy to find the DEV API as one of those.

My idea was simple:

Get the properties of this article.
Update the title using two of the properties (positive_reactions_count and comments_count).

The source

I use PHP, which is one of my favorite programming languages.

Get article properties

function getArticleProperties($articleId)
{
    // Prepare URL
    $url = 'https://dev.to/api/articles/' . $articleId;

    // Prepare headers
    $headers = [
        'api-key: 1234567890abcdef',
    ];

    // Prepare method
    $method = 'GET';

    // Execute request
    $curlHandle = curl_init();
    curl_setopt($curlHandle, CURLOPT_URL, $url);
    curl_setopt($curlHandle, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlHandle, CURLOPT_CUSTOMREQUEST, $method);
    curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
    $response  = curl_exec($curlHandle);
    curl_close($curlHandle);

    return json_decode($response, true);
}

Update article title

function updateArticleTitle($articleId, $articleTitle)
{
    // Prepare URL
    $url = 'https://dev.to/api/articles/' . $articleId;

    // Prepare payload
    $payload = json_encode(
        [
            'article' => [
                'title' => $articleTitle,
            ],
        ]
    );

    // Prepare headers
    $headers = [
        'Content-Type: application/json',
        'Content-Length: ' . strlen($payload),
        'api-key: 1234567890abcdef',
    ];

    // Prepare method
    $method = 'PUT';

    // Execute request
    $curlHandle = curl_init();
    curl_setopt($curlHandle, CURLOPT_URL, $url);
    curl_setopt($curlHandle, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlHandle, CURLOPT_CUSTOMREQUEST, $method);
    curl_setopt($curlHandle, CURLOPT_POSTFIELDS, $payload);
    curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
    $response  = curl_exec($curlHandle);
    curl_close($curlHandle);
}

Putting it all together

// Prepare article ID
$articleId = 715066;

// Get article properties using the API
$articleProperties = getArticleProperties($articleId);

// Update article title using the API
updateArticleTitle($articleId, 'This article has ' . $articleProperties['positive_reactions_count'] . ' positive reactions and ' . $articleProperties['comments_count'] . ' comments');

A cronjob is executing this as a CLI script every 60 seconds.

Inspiration

This article is heavily inspired by an awesome YouTube video I saw earlier this year.

Use components without a frontend framework

Malte Riechmann — Thu, 27 May 2021 11:49:25 +0000

Frontend frameworks

Within this post, I will show you one, of many ways to use components without a frontend framework. Do not get me wrong, I like frameworks like Vue.js, React, or Angular. At our company, we write JavaScript with Vue.js on a daily basis.

But sometimes those frameworks are too much. Especially when building simple websites instead of complex web applications. In these cases, we do not use a framework at all and just write HTML, CSS, and JavaScript.

Components

If your source code gets messy there is often an easy way to improve it. Move your source code into smaller chunks – divide and conquer.

Splitting your source code into multiple components is a well-known way to structure your project. Things get isolated, readable, clear, reusable, extendable, and maintainable. In fact, that is what most of the frontend frameworks do themselves.

Welcome to BEM

BEM (Block Element Modifier) is a methodology to organize your frontend. It is mostly known in the world of CSS, but I am going to show you how to use it for JavaScript, too. Please remember, BEM is a methodology and not a framework. It will come with zero dependencies.

A card block

In BEM the components are called blocks. It is just different terminology for the same thing.

Now, imagine a card block (source code).

HTML

We use HTML for the structure and content of the card block. Of course, you can use programming languages, template engines, or other tools to improve the HTML part of the block.

<article class="card card--highlight">
    <figure class="card__figure">
        <img class="card__image" src="#">
        <figcaption class="card__caption">#ffed00</figcaption>
    </figure>
    <h2 class="card__headline">Corporate yellow</h2>
    <p class="card__description">This yellow is defined as #ffed00. It is a very nice color. It is one of our corporate colors at visuellverstehen.</p>
</article>

CSS

We use CSS for the presentation and style of the card block. Of course, you can use pre processors, post processors, or other tools to make CSS more comfortable to use.

.card {
  font-family: sans-serif;
  line-height: 1.5;
  padding: 1rem;
  max-width: 20rem;
  border: 0.25rem solid #f6f6f6;
}

.card.card--highlight {
  border-color: #ffed00;
}

.card__figure {
  margin: 0;
}

.card__image {
  display: block;
  width: 100%;
  height: 6rem;
}

.card__caption {
  padding-top: 0.5rem;
  padding-bottom: 0.5rem;
}

.card__headline {
  font-size: 1.5rem;
  font-weight: bold;
}

JavaScript

We use JavaScript for the functionality of the card block. Of course, you can use all kinds of tools to improve how you write JavaScript (Babel, TypeScript, ESLint, webpack, …).

(function () {

  var initializeCard = function($card) {
    console.log('Do whatever this $card block should be doing.');
  };

  document.addEventListener('DOMContentLoaded', function() {
    var $cards = document.querySelectorAll('.card');

    for (var i = $cards.length - 1; i >= 0; i--) {
      initializeCard($cards[i]);
    }
  });

}());

Sometimes blocks have to communicate with each other. For that, there are at least two good options: Custom events and stage management.

Learn the basics

It is remarkable how much can be done just using HTML, CSS, and JavaScript. That is one reason why I encourage everyone to learn the basics.

DEV Community: visuellverstehen

Access Current Entry in Custom Validation Rule

Create an entry approval workflow with Statamic Revisions

Who is this article for?

What we are about to do

What's a working copy?

Let's bring in the data!

Let authors know that there's something to review

Giving Feedback

Create a feedback form

Tracking feedback and dates

Handling publication

Conclusion

Effortless Language Redirection - TYPO3 Extension

Introduction

What does t3languageredirection actually do?

Why t3languageredirection?

How to use t3languageredirection?

Conclusion

Accessible website: 7 steps to better accessibility and SEO performance

7 steps you shall take

1. Clean structure of the website

2. Clearly formulated headings in the correct order

3. Correct labeling of links and buttons

4. Loading speed

5. Images and SVGs

6. Sitemap

7. Page title

More accessibility and SEO performance for your website

New git guidelines: We have switched to Conventional Commits

Discuss, decide, repeat

New git guidelines

Repositories

Branches

Commits

One year of coding – recommendations for beginners from a beginner

Know the basics

Learn about coding principles

Start with proper HTML

Accessibility matters

Structure your CSS

Fin.

Our tech stack in 2022

Preface

Clarification

Our tech stack

Core products

What people call »Backend«

What people call »Frontend«

What people call »DevOps«

Honorable mentions

Happy coding

How to add pagination to your custom relationship fieldtype in Statamic

Common mistakes when writing CSS with BEM

Software development is a team effort

Learn proper BEM

Four most common mistakes

1. Wrongly nested blocks and elements

❌ Wrong

✅ Correct

2. Great-grandchildren

❌ Wrong

✅ Correct

3. Modifiers without a base class

❌ Wrong

✅ Correct

❌ Wrong

✅ Correct

4. Too big blocks

❌ Wrong

✅ Correct

Automate stuff

A little Slack app to ask our team social questions

Changes coming from the pandemic

A little idea

Questions to ask

Source code

This article has 61 positive reactions and 24 comments

TL;DR

Addicted to numbers

What does `t3languageredirection` actually do?

Why `t3languageredirection`?

How to use `t3languageredirection`?