DEV Community: Visual Composer

Debugging a problem

Filips Masolovs — Mon, 11 May 2020 18:13:52 +0000

"If debugging is the process of removing software bugs, then programming must be the process of putting them in."

Edsger Dijkstra

I like this quote! Whenever I am asked something like: "How did this bug appear?" my first response would usually be: "Someone just put it there..."
And then we can check!?

However, being in this whole new world for less then a year debugging is currently the hardest part for me! Sometimes you open the console and the error is blunt and obvious like "Cannot read property 'smth...' of undefined" most of the times this type of issue will be pretty easy. Obviously there can be times when you struggle to realize why on earth the object or whatever is undefined, but still, probably this is workable!
Then there are hard errors like object doesn’t support property, Uncaught RangeError, ...is not a function and such! These usually take much more time for me to debug and I definitely need to learn to use debugger in such cases more properly, but about this more in the future!

But then there is hell. And by hell I mean when all the code is loaded, there are no errors in the console, you see what you want to see in the DOM, but... but the functionality isn't working! This is extremely tedious when you know for sure that it was working before.
And this is the type of "bug" that frustrates me the most for now!
When I encounter bugs I usually at the least know where to check, but in cases like this, it is from a to z... So what to do? Dig?

What are your stories with debugging and bugs in general?
Care to share?

P.S. I would like to write an article about my thoughts on design docs next! Would you be interested in reading it?

Become more productive with these 5 terminal tips

Nikita Hlopov — Mon, 16 Mar 2020 13:44:14 +0000

Five small tips to improve your terminal skills that I've learned from my teammate.

Change directory from root
Line navigation
Remove the line
Repeat the previous command with sudo
Suggestions with Tab button

1. Change directory from root

From any directory location in your terminal, you can start directory change from the root folder. Right after cd command add a Space and a / to begin change. E.g.:

cd /

and then:

cd /var/log/

2. Line navigation

Navigate through your line with ease. Either jump to the start and end of the line:

fn + shift(⇧) + ← - Jump to the start of the line
fn + shift(⇧) + → - Jump to the end of the line

or jump by word:

alt(⌥) + ← - Jump to the previous word
alt(⌥) + → - Jump to the next word

3. Remove the line

This command will remove all text in the current line and leave cursor blinking at the start:

ctrl(⌃) + u

4. Repeat the previous command with `sudo`

Very handy if you need to repeat the command with superuser permissions:

sudo !!

5. Suggestions with Tab button

Double-clicking on Tab button while writing a path to a file will show you suggestions (contents) of the directory. It comes in handy when you need to type in a long path.

That's it for now. Happy coding. 👩‍💻👨‍💻

Cover image via Unsplash by Goran Ivos

How to clean your git history

Slava Vasenin — Mon, 16 Mar 2020 12:31:04 +0000

Hi!
I want to share you a short instruction on how to remove wrong or mistaken commits from a remote repository when you don't want to make a revert.

Check changes and find what commits you want to remove.

$ git log --stat

Use the interactive rebase command.

$ git rebase -i HEAD~X

Put the number of commits instead of X which you want to remove. Better to add a bit more to view the previous ones also. So, you need to remove 1 commit add number 3.

You will see something like this:

pick a0b45b373 Dynamic field featured image url fixed
pick 8e8d27747 Update render condition for feedback popup component
pick 843770a32 Add dev.to version

# Rebase 680ac7c26..843770a32 onto 680ac7c26 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit

I use Vim as default text editor for Git.

Replace the word pick with the word drop or d for those commits that you want to remove. I remove only one, but I also checked and see that previous commits not related to my changes.

pick a0b45b373 Dynamic field featured image url fixed
pick 8e8d27747 Update render condition for feedback popup component
d 843770a32 Add dev.to version

Save and exit from your editor.

Check git status.

$ git status
On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

In some cases, there can be merge conflicts after rebase. Follow instructions to solve them.

The next step is to push it to your remote repository. You need to force this push because the remote repository will think that your current branch is behind.

git push -f

Go and check your remote repository.

That it. Thanks and Good luck 🚀

Cover image by Diana Mounter

⚛️ Initiate a React app with multiple components on a single DOM element

Nikita Hlopov — Mon, 09 Mar 2020 13:22:10 +0000

In this article, I'll go through the use case of rendering multiple React components to a single DOM element of a React app.

There might be a case when your app consists of independent components that might need to be initiated from different places on different conditions but inside a single container.

Turns out that React can handle these cases with ease.

Initiate a generic React app
Initiate a React app with multiple components

Initiate a generic React app

Usually, the generic React app begins like so:

HTML have a single div container element:

<div id="app"></div>

The React part is a single component that gets rendered inside a given DOM container:

const appContainer = document.getElementById('app')

function Form () {
  const handleSubmit = (e) => {
    e.preventDefault()
  }
  return (<form onSubmit={handleSubmit}>
    <input type="email" placeholder="email@example.com" />
    <input type="submit" value="Submit" />
  </form>)
}

ReactDOM.render(<Form />, appContainer)

Initiate a React app with multiple components

To initiate your app with multiple components you need to wrap them in a React Fragment inside the ReactDOM.render method.

Fragments let you group a list of children without adding extra nodes to the DOM.

const appContainer = document.getElementById('app')

function Form () {
  const handleSubmit = (e) => {
    e.preventDefault()
  }
  return (<form onSubmit={handleSubmit}>
    <input type="email" placeholder="email@example.com" />
    <input type="submit" value="Submit" />
  </form>)
}

function Content () {
  return <h2>Subscribe to our newsletter</h2>
}

ReactDOM.render(
  <>
    <Content />
    <Form />
  </>, appContainer)

Conclusion

The good part about it is that you can wrap those components in a variable and render them based on a condition if necessary.

const formComponent = <Form />
const contentComponent = isVisible ? <Content /> : null

const components = <>
  {contentComponent}
  {formComponent}
</>

ReactDOM.render(components, appContainer)

In a complex environment (ours is a WordPress plugin), it is a great way to control what gets delivered to the user.

See full example on CodePen:

5 reasons to write Semantic HTML

Nikita Hlopov — Wed, 04 Mar 2020 17:47:35 +0000

I’ll go through a list of 5 reasons why web developers should pay more attention to semantic HTML.

Another repost of my original article on the importance of writing semantic HTML

Understandable code
Screen readers
Search engines (SEO)
Usability (UX)
Default styling

What does MDN say about Semantic HTML:

In programming, Semantics refers to the meaning of a piece of code — for example ... "what purpose or role does that HTML element have" (rather than "what does it look like?".)

So the number one reason is:

1. Understandable code

By giving meaning to your markup, you make it more understandable. From a human perspective semantic code is more readable, understandable and easier to maintain. Imagine looking at the code like this:

<div id=”brown-fox”>
  <div>A story of quick brown fox</div>
  <div>The quick brown fox jumps over the lazy dog.</div>
  <div>Properties:</div>
  <div>- quick</div>
  <div>- brown</div>
  <div>- jumpy</div>
<div>

The same structure but with meaningful tags:

<section id=”brown-fox”>
  <h2>A story of quick brown fox</h2>
  <p>The quick brown fox jumps over the lazy dog.</p>
  <h3>Properties:</h3>
  <ul>
    <li>quick</li>
    <li>brown</li>
    <li>jumpy</li>
  </ul>
<section>

You can immediately spot the difference. Straight off the bat, you can tell what each part of the structure does.

2. Screen readers

Not only humans (programmers) have the need to understand the meaning of the page structure, so do the machines, one of them are screen readers.

A screen reader is a form of assistive technology which is essential to people who are blind, as well as useful to people who are visually impaired, illiterate, or have a learning disability.
—Wikipedia

A screen reader analyzes the contents of the web page and outputs the results via speech. This means whatever a screen reader sees, it will read. So it’s quite important to structurize your web page with a meaning. However modern screen readers are quite “smart” and handle web pages very well.

Both MAC and Windows have built-in screen readers. For MAC it is VoiceOver, for Windows it is Narrator.

3. Search engines (SEO)

Moving on from one machine type to another. The structure of your web page can affect SEO (Search Engine Optimization) results.

SEO stands for ‘Search Engine Optimization’. It’s the practice of optimizing your web pages to make them reach a high position in the search results of Google or other search engines. —YOAST

However semantic HTML is not the primary factor that affects the SEO of the page, but it helps page crawlers understand the structure of this page. A page with proper semantic HTML will have a chance to rank higher in the search results.

4. Usability (UX)

By using semantics not only you are aiding the machines, but you can also help people and make their lives better. The use of proper semantic HTML can boost up your website usability and accessibility. I think you all will agree with me, that you like resources that are intuitive and easy to use.

Sometimes small adjustments or fine-tuning can make a huge difference for users. For instance, adding a label element next to input, or adding a proper attribute to the same input element.

5. Default styling

The good thing about semantic HTML, that elements come with default styling. Even without additional CSS the page that is built with proper semantic HTML will look good, be accessible and is going to provide the meaning and outline the structure.

Even though the default styling can vary from browser to browser, the main look of the page will remain.

Default styling comes to the rescue when something goes wrong and your CSS fails.

Below I’ll share a list of resources I have found useful when I was learning about semantic HTML and Semantic Web in particular.

Blogs:

Docs:

Videos:

How to measure deployment frequency for WordPress plugin

Slava Vasenin — Tue, 03 Mar 2020 15:02:40 +0000

One year ago I read a very great book about DevOps science "Accelerate".

There was a chapter about measurements that can be used to answer the question: Does your company has High-performance team in the development?

These measurements:

Deployment Frequency
Lead Time for changes
MTTR
Change Failure rate

One of the most interesting points is Deployment Frequency and we had a long discussion about this in my team about that. The book says that the high-performance team should deliver on-demand, multiple deploys per day.

The problem is that if we will publish one plugin every day multiple times in "WordPress.org" people won't like it because there are no automatic updates for Wordpress plugins in the admin dashboard.

So, Publishing so frequently isn't an option, but the concept to have a deliverable product as often as the possible sound really useful.

We use a trunk-based development branching model. What does it mean?

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’(master), resist any pressure to create other long-lived development branches by employing documented techniques. They, therefore, avoid merge hell, do not break the build, and live happily ever after.

There is a master branch were we merge all pull requests. Is it safe? From point of continues integrations, we run tests pipeline for every commit and every merge. Sound safe! How true is it? Not sure. No one during the merge of the pull request thinks it can be delivered to the customer at once.

The only thing left is to update the release brunch as frequently as possible. Here is our scenario:

Developer crates pull request. Before all CI pipeline's tests have been successfully completed.
A reviewer checks code and confirms this pull request as valid.
A reviewer merges pull request.
Release engineer checks during the day the state of the master branch and if it has updates, decides are this code safe for the update in the current release branch.

So every update counts as deployment. Makes sense, isn't it?

Conclusion

If you have any suggestions or you want to share what kind of practices you use in your company, please welcome to write comments :)

Thanks and Good Luck 🚀

Working remotely! YES or NO?

Filips Masolovs — Wed, 12 Feb 2020 15:56:22 +0000

So, today I decided to ponder about working remotely!
Its' pros and cons, whether I really like it or no and is it even productive.

First of all, I noticed that on the days when I visit the office I am so drained out by the end of the day that I don't want to do anything anymore. This is related to a 2h daily commute that I need to tackle in order to get to the office and to the fact that working in the office quite honestly just takes more out of you due to always chatting with someone, joggling this and that and quite simple more things to do then just tasks at hand.
When I work at home I can easily do some extra work at 8PM, 9PM sometimes even 10PM. No problem. I am not tired from driving for 2h and working at home is quite simple more calming.

Secondly, I have to say(even though this is very specific from person to person) that my personal productivity level is better at home. And here I mean not the hours spent on work, no-no, I mean the overall amount of work done within a day! Obviously if you lack focus and can't sit for a while at a computer thinking about how to solve an unsolvable problem, maybe, this is not the way for you!

To conclude, I would like to say, that I really like working remotely!
My productivity is better. I can work more. I am not tired by the end of the day.

Did you try working remotely? Maybe with a friend?
How did it go? And if you haven't, why?

Tell me about your experience...

How to get WordPress plugin release in GitHub actions

Slava Vasenin — Mon, 10 Feb 2020 15:18:16 +0000

We started to use GitHub actions to build Visual Composer release candidates in GitHub. This action will prepare a proper zip archive file which we can use to update our plugin in Wordpress.org.

We decided that the release will be built on the new tag. The tag will be the version of the published release.

on:
  push:
    tags:
      - '*'

We already had the script which was able to create a valid zip archive of Visual Composer Website Builder for Wordpress.org. It looks like this.

$ node _infrastructure/vcwb-builder/builder plugin -b VERSION -p ./_infrastructure

Yeah, this script will set plugin version also -b VERSION. The question is how to get the version from GitHub tag. There is access to $GITHUB_REF where we can get tags. I decide to create variable get_version which can be used in other steps of the job.

- name: Get the version
  id: get_version
  run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//}

Then we just need to use steps.version_version in the next step.

- name: Build project
  run: |
    yarn install
    node _infrastructure/vcwb-builder/builder plugin -b ${{ steps.get_version.outputs.VERSION }} -p ./_infrastructure

The next action is to create Github release itself.

- name: Create Release
  id: create_release
  uses: actions/create-release@v1.0.0
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    tag_name: ${{ github.ref }}
    release_name: ${{ github.ref }}
    draft: false
    prerelease: false

After release creation needs to upload our zip archive. I use actions/upload-release-asset@v1.0.1 action for that.

- name: Upload Release Asset
  id: upload_release_asset
  uses: actions/upload-release-asset@v1.0.1
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    upload_url: ${{ steps.create_release.outputs.upload_url }}
    asset_path: ./_infrastructure/visualcomposer.zip
    asset_name: visualcomposer.zip
    asset_content_type: application/zip

That's it. The full version of the configuration file you can check here.

Good luck ✌️

The start of my journey!

Filips Masolovs — Mon, 10 Feb 2020 11:58:23 +0000

01.08.2019
That was the day when my "development" journey started!
I will clarify immediately that the only reason why I put "development" in quotation marks is because I still consider myself far from a decent developer.

Being a frontend-dev my journey started with HTML, it was easy. I mean with HTML you don't need to think a lot of super complicated logic. What you see is what you get, so yeah those steps were easy.
After that came CSS, I can't say that it is particularly hard, but some CSS stuff is confusing and misleading. Like I still sometimes wonder: "Do I justify or align here?" when working with flex-box. And some things like gradient transition require hacks to work, but these are very easily available on the web.

But then came the hard part, JS, React.JS...
Here's where things get tricky, here you have to implement logic, use functions and battle Sauron not to get any errors in your console.
For the most part I manage to write the most part of code when I am creating something from scratch and get stuck only at the end and here and there need some refactoring to be done, but the biggest issue for me comes when I battle some already prewritten code. This is where I get stuck.

But I guess the journey doesn't supposed to be easy? Does it? I mean if it would, what would be the point? So yes, even if I do struggle now on things that may not be so hard, I still see how much I have grown personally in the last few months and I still feel that I can grow further in this industry...

TTYS, Mr.Masolov

Writing and debugging Cypress tests

Nikita Hlopov — Thu, 30 Jan 2020 22:36:49 +0000

I want to share the knowledge I and my team gained after implementing Cypress e2e tests in our project.

Intro

About a year ago we've (Visual Composer dev team) picked Cypress as our main tool for e2e tests. It was a new experience for the whole team as none of us was familiar with e2e testing. Over that period of time not only we've covered a large amount of functionality with tests but also we've learned quite a bit.

Recently I've made a small demo for our team of developers to summarise what we already know. The purpose of this demo was to:

Share knowledge and to establish common understanding and principles for e2e tests among all developers in our team

That inspired me to write an article.

Outline

Conventionally we can split the app testing process into two parts:

writing tests - when a developer actually writes the code
debugging tests - fixing issues when the test is failing

So that's what I'm going to share with you in a form of tips and solutions.

NOTE: Even though our product may be very specific I think these tips can be applicable to a wide variety of projects.

Writing tests

These tips helped me to write tests and to tackle issues faster and with ease.

1. Cypress syntax is similar to jQuery

If you know jQuery then understanding that Cypress commands are similar to the jQuery counterparts like selectors and chaining will make your Cypress learning curve much smoother.

E.g. the cy.get() command will return a collection of elements. Knowing that you'll be able to handle further chaining or resolve the possible error.

2. Cypress is lacking some features

Some of the functionality cannot be tested like hover effect or testing within and iframe.

The good part is that the Cypress team is aware of that and communicating to the community on possible solutions and workarounds.

3. Cypress resources

Continuing the thought from the previous point, I really like Cypress API documentation and their GitHub repo's Issues.

I was able to resolve almost every problem just by checking their docs or searching GitHub issues. Stackoverflow helped me as well. 😅

Overall I find the Cypress team quite engaging and willing to help.

4. Folder structure

We are sticking to the recommended folder and file structure in the official Cypress docs.

Since our project is quite large and multiple components that need to be tested are stored in multiple repositories, having a unified structure helps a lot.

5. Cypress strange behavior

In our case sometimes Cypress may render duplicate elements. I'm not sure if this is a project-specific issue, but I couldn't find any information on that topic.

The point is if a specific issue is occurring in your tests, you need to share that information across your team and prepare a solution for such cases.

Btw, the solution to our issue is since we're only checking the single element we're adding an index with a bracket notation to select the first element.

cy.get('.vce-row-content')[0]
  .children()
  .should('have.length', 3)

6. CSS values are computed values

When checking for CSS values it's important to understand that Cypress will compare your assertion to a computed CSS value. That is equal to the one you get when using the getComputedStyle() method.

Debugging

We separate debugging into two types.

Local
Pipeline

Local debugging

Usually, it's quite simple but sometimes developers get stuck and having a hard time resolving the issue. Even though the Cypress itself helps to troubleshoot.

1. Carefully read the error message

Developers are in a hurry and don't read the error message till the very end or read it superficially.

Sometimes it may contain a clue or a possible solution.

2. Additional data in the console

To retrieve additional data click on the step and the data will be outputted in the console.

3. Comment out commands

Comment out commands to get to the problem point faster. We have quite complex logic behind our tests, so they take quite a long time to run. In order to make the debugging process faster, I use that technique.

/* global describe, it, cy */

const ELEMENT_NAME = 'Text Block'

describe(ELEMENT_NAME, function () {
  it('Adds element to the page, checks automatically added elements, checks attributes', function () {
    cy.fixture('../fixtures/textBlock.json').then((settings) => {
      cy.createPage()
      cy.addElement(ELEMENT_NAME)

      // cy.setTinyMce({
      //   title: 'Content',
      //   text: settings.text,
      //   elementType: {
      //     name: settings.elementType.name
      //   },
      //   alignment: {
      //     name: settings.alignment.name
      //   }
      // })

      cy.setClassAndId(settings.customId, settings.customClass)

      // cy.setDO(settings.designOptions)

      cy.savePage()
      cy.viewPage()

      cy.get('.vce-text-block')
        .should('have.class', settings.customClass)
        .should('have.attr', 'id', settings.customId)

or go straight ahead to the exact page (our tests generate site pages in WordPress)

/* global describe, it, cy */

const ELEMENT_NAME = 'Text Block'

describe(ELEMENT_NAME, function () {
  it('Adds element to the page, checks automatically added elements, checks attributes', function () {
    cy.fixture('../fixtures/textBlock.json').then((settings) => {
      // cy.createPage()
      // cy.addElement(ELEMENT_NAME)

      // cy.setTinyMce({
      //   title: 'Content',
      //   text: settings.text,
      //   elementType: {
      //     name: settings.elementType.name
      //   },
      //   alignment: {
      //     name: settings.alignment.name
      //   }
      // })

      // cy.setClassAndId(settings.customId, settings.customClass)

      // cy.setDO(settings.designOptions)

      // cy.savePage()
      // cy.viewPage()

      cy.visit('http://localhost:8888/wp/auto-draft-4')

      cy.get('.vce-text-block')
        .should('have.class', settings.customClass)
        .should('have.attr', 'id', settings.customId)

Pipeline debugging

We use two different environments to run Cypress on the pipeline:

CircleCI on GitHub for our main project
Gitlab CI on GitLab for other projects

They both basically do the same stuff, the main difference is the interface.

On pipeline we use Docker image with:

Apache server
Pre-installed WordPress
Pre-installed theme
Pre-installed plugins

Debugging on the pipeline is essentially similar to a local.

1. Read the error message

Like in the Local debugging read the error, half of the times it will be enough. The image below is the error message from the GitLab CI terminal.

2. See artifacts (screenshot or video)

By default Cypress have screenshots enabled, but we also enabled video recording. To improve performance a little, we've enabled video recording only on failure. Video recording can be enabled in the cypress.json config file:

"video": true

Once the test is failed now we can check a screenshot or a video.

Artifacts on GitLab CI:

Artifacts on CircleCI:

3. Plugins for debugging

The following plugins can be used both locally and on the pipeline. We're saving up resources and using them rarely only for intricate cases. For the most part, it's enough with error messages and artifacts, but it's good to know that such plugins exist.

Saves the Cypress test command log as a JSON file if a test fails https://github.com/bahmutov/cypress-failed-log
A Cypress plugin that sends all logs that occur in the browser to stdout in the terminal https://github.com/flotwig/cypress-log-to-output

Inner docs

If your team or project has an inner knowledge base or even if you don't, start documenting. Over time there's just too much information piling in the heads of developers.

We've begun documenting howtos and practices on e2e testing. That way all developers now have a point of reference.

You don't have to scale to full-blown documentation at once. Start with a single document and a few code snippets. 😉

Conclusion

These are the techniques we use to write the e2e tests. I do hope that people can draw from our knowledge and improve their testing. Let us know what techniques and methods you are using by replying in the comments.

Check out our tests they are available in our GitHub repo.

DEV Community: Visual Composer

Debugging a problem

Become more productive with these 5 terminal tips

1. Change directory from root

2. Line navigation

3. Remove the line

4. Repeat the previous command with sudo

5. Suggestions with Tab button

How to clean your git history

⚛️ Initiate a React app with multiple components on a single DOM element

Initiate a generic React app

Initiate a React app with multiple components

Conclusion

5 reasons to write Semantic HTML

1. Understandable code

2. Screen readers

3. Search engines (SEO)

4. Usability (UX)

5. Default styling

How to measure deployment frequency for WordPress plugin

Conclusion

Working remotely! YES or NO?

How to get WordPress plugin release in GitHub actions

The start of my journey!

Writing and debugging Cypress tests

Intro

Outline

Writing tests

1. Cypress syntax is similar to jQuery

2. Cypress is lacking some features

3. Cypress resources

4. Folder structure

5. Cypress strange behavior

6. CSS values are computed values

Debugging

Local debugging

1. Carefully read the error message

2. Additional data in the console

3. Comment out commands

Pipeline debugging

1. Read the error message

2. See artifacts (screenshot or video)

3. Plugins for debugging

Inner docs

Conclusion

4. Repeat the previous command with `sudo`