Forem: tony

Laravel on Steroids! Get 10x Speed in Your App Development

tony — Mon, 30 Sep 2019 15:42:59 +0000

- DB-MVCr-MPR-TA

Part 3: Testing Model Relationships in Laravel — POLYMORPHIC

tony — Sun, 29 Sep 2019 16:27:49 +0000

Part 3: Testing Model Relationships in Laravel — POLYMORPHIC

This part deals with more complex model relationships, the polymorphic type. Just like before, we shall stick to the official documentation examples and work out befitting tests. To have a low down on the earlier parts see link directly below 👇

Part 1: Intro and Schema Tests
Part 2: Testing Basic Model Relationships
Part 3: Testing Polymorphic Relationships ⏯

POLYMORPHIC RELATIONSHIPS

A polymorphic relationship allows a target model to belong to more than one type of model using a single association. — Laravel.com

1. One-to-One Polymorphic Relationship

A one-to-one polymorphic relation is similar to a simple one-to-one relation; however, the target model can belong to more than one type of model on a single association.

Scenario:

A blog Post and a User may share a polymorphic relation to an Image model. Using a one-to-one polymorphic relation allows you to have a single list of unique images that are used for both blog post s and user accounts

morphTo()

— An image table can be morph ed in to any model (i.e serve many different models), eg User or Post model in our case.



// App/Image.php
...
public function imageable() 
{ 
 return $this->morphTo(); 
}

morphOne()

— A user/post model can morph one instance of the same image model table (i.e make use of same image table but one record per user/post).
— INVERSE of morphTo relationship.



// App/User.php
...
public function image() 
{ 
 return $this->morphOne(Image::class, 'imageable'); 
}

Files relevant to this test 👇



- **MODEL FILES(App/)
 -- User.php 
 -- Post.php
 -- Image.php

- **MIGRATION FILES(database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\27\100604\create\posts\table.php
 -- 2019\09\28\143143\create\images\table.php

- **MODEL FACTORY FILES(database/factories/)
 -- UserFactory.php 
 -- PostFactory.php
 -- ImageFactory.php

- **UNIT TEST FILES(tests/Units/)
 -- UserTest.php 
 -- PostsTest.php
 -- ImagesTest.php

2. One-to-Many (Polymorphic)

A “one-to-many polymorphic” relation is similar to a simple one-to-many relation; however, the target model can belong to more than one type of model on a single association. — Laravel.com

Scenario:

Users of your application can “comment” on both posts and videos. Using polymorphic relationships, you may use a single comments table for both of these scenarios.

morphTo()

— A comment table can be morph ed to any model (i.e serve many different models), eg Video or Post model in our case.



// App/Comment.php
...
public function commentable() 
{ 
 return $this->morphTo(); 
}

morphMany()

— A video/post model can morph many instances of the same comment model table (i.e make use of same comment table for many records).
— INVERSE of morphTo relationship.



// App/Video.php
...
public function comments() 
{ 
 return $this->morphMany(Comment::class, 'commentable'); 
}

Files relevant to this test 👇




**MODEL FILES(App/)

-- User.php 

-- Post.php

-- Video.php

-- Comment.php
**MIGRATION FILES(database/migrations/)

-- 2019\09\28\211240\create\videos\table.php

-- 2019\09\28\221627\add\commentable\id\and\commentable\type\to\comments\table.php
**MODEL FACTORY FILES(database/factories/)

-- VideoFactory.php
**UNIT TEST FILES(tests/Unit/)

-- PostsTest.php

-- VideosTest.php

-- CommentsTest.php

Many-to-Many (Polymorphic)

In progress…

Kindly check back soon

👉Part 1: Intro and Schema Tests
👉Part 2: Testing Basic Model Relationships
⏯Part 3: Testing Polymorphic Relationships

Part 2: Testing Model Relationships in Laravel — BASIC

tony — Sun, 29 Sep 2019 16:20:23 +0000

Part 2: Testing Model Relationships in Laravel — BASIC

Some Laravel model relationship unit tests

100% code coverage is hardly achievable in code testing, we do aim closer but some tests are really boring. In this multipart post I helped you edge closer to 100% code coverage by writing some 5% of the tests you need in all your Laravel apps — the boring and often overlooked tests.

Eloquent relationships are ever present in every Laravel app but how do you ensure the expected models are all connected? This could be your cheatsheet for eloquent relationship tests. We are going to write tests that ensure all our models have relevant model connections and that they are correctly set.

Part 1: Intro and Schema Tests
Part 2: Testing Basic Model Relationships ⏯
Part 3: Testing Polymorphic Relationships

THE RELATIONSHIPS

The word relationship is expected to involve at least two entities, thus every eloquent relationship has two parties, (a). The first relationship and (b). The Inverse relationship (either of the models could be made the first but a more influential or parent-esque model is okay as the first). As we write model relationship tests it is only right to test from the two concerned ends, thus we shall be writing for both first and inverse relationships.

In mosts cases, relationship examples used in the official Laravel documentation will be used in this post. Your use-cases may be different, simply adapt the tests to your specific scenario.
there are places where I included more than one method of testing, any of them is just fine.
Watch out! Whenever a new model is introduced I add a schema test. Do not be surprised if some files have more test than others.

1. One To One Relationship

A one-to-one relationship is used to define relationships where a single model has a unary relationship with another model. Both models can own only one instance of the each other.

Scenario:

We have User and Phone models. A user is allowed to register only one phone number on the app, this means one unique phone entry for a given user in the phone table. This relationship can pan out as hasOne() and belongsTo() relationships.

hasOne()

— A user has one phone registered (FIRST).



// App/User.php
...
public function phone() 
{ 
 return $this-\>hasOne(Phone::class); 
}

THE TEST : A user owns a phone, a phone is a unique entity thus we test that the phone is an instanceOf a Phone class. Second method tests existence of a relationship by asserting with a successful count.

belongsTo()

— Any registered phone belongs to a single user
— INVERSE of hasOne relationship.



// App/Phone.php  
...
public function user() 
{ 
 return $this-\>belongsTo(User::class); 
}

THE TEST : A phone belongs to a user, a user is a unique entity thus we tested that a user is an instanceOf a User class.

Files relevant to this test 👇



- **MODEL FILES** (App/)
 -- User.php 
 -- Phone.php

- **MIGRATION FILES** (database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\26\154439\create\phones\table.php

- **MODEL FACTORY FILES** (database/factories/)
 -- UserFactory.php 
 -- PhoneFactory.php

- **UNIT TEST FILES** (tests/Units/)
 -- UserTest.php 
 -- PhonesTest.php

Simply run the test suite and you should get a green.

$ pu or putu (or any nice alias you gave to your unit test commands)

or $ vendor/bin/phpunit

All tests passed

5 tests? Yeah, schema test inclusive. See the list below:



1. User schema test 
2. Phone schema test
3. User-\>hasOne(phone) test (2 methods)
4. Phone-\>belongsTo(user) test

Tweak your code, goof around. Just have fun.

2. One To Many Relationship

A one-to-many relationship is used to define relationships where a single model owns any amount of other models. — Laravel.com

Scenario:

A blog post with an infinite number of comments or an author (user) with many articles or comments. We are going to write a test for Post and Comment models relationship. Thus this relationship can pan out as hasMany() and belongsTo() relationships.

hasMany()

— A post has many comments on it (FIRST).



// App/Post.php
...
public function comments() 
{ 
 return $this-\>hasMany(Comment::class); 
}

THE TEST : Since a post has many comments, the comments are returned as collections on the post instance that is why we are able to do iterations when rendering results in app views. It is correct that we test a post’s comments as an instanceOf a collection.

belongsTo()

— A comment belongs to a post
— INVERSE of hasMany relationship.



// App/Comment.php
...
public function user() 
{ 
 return $this-\>belongsTo(Post::class); 
}

THE TEST : A comment belongs to a post, a post is a unique entity thus we test that a post is an instanceOf a Post class. This is similar to $phone->user test we had earlier.

Files relevant to this test 👇



- **MODEL FILES** (App/)
 -- User.php 
 -- Post.php
 -- Comment.php

- **MIGRATION FILES** (database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\27\100604\create\posts\table.php
 -- 2019\09\27\100620\create\comments\table.php

- **MODEL FACTORY FILES** (database/factories/)
 -- UserFactory.php 
 -- PostFactory.php
 -- CommentFactory.php

- **UNIT TEST FILES** (tests/Units/)
 -- UserTest.php 
 -- PostsTest.php
 -- CommentsTest.php

If you run the test at this point it should all pass.

Heads up:

As depicted in the scenario section, this same One To Many tests can be replicated on User-Post , User-Comment and other model relationships that fit into the scenario (I have all the tests in this Github repo )_. A user can create many posts and many comments as well, these are hasMany() relationships. Writing model relationship tests will become natural to you when you fully understand how the eloquent relationships work.

3. Many-to-Many Relationship

A many-to-many relationship is used to define relationships where the two models involved can have many instances of each other.

Scenario:

A user can play many roles, and the roles are also shared by other users. Also for doctors and medical specialties, a specialty can be shared by many doctors while a doctor can be specialized in many specialties. Our test will be for User and Role models relationship.

belongsTo means a model that is already existing that another model fits into but have no privilege to create. This is different from hasOne or hasMany whose verb depict that a given model owns or creates another. On both models involved, the relationship is defined as belongsToMany().

belongsToMany()

— A user belongs to many roles (FIRST).



// App/User.php
...
public function roles() 
{ 
 return $this-\>belongsToMany(Comment::class); 
}

belongsToMany()

— A role belongs to many users
— INVERSE of belongsToMany relationship. Kinda recursive.



// App/Role.php
...
public function users() 
{ 
 return $this-\>belongsToMany(User::class); 
}

NB : role\user table must be migrated for this tests to pass.

Files relevant to this test 👇



- **MODEL FILES** (App/)
 -- User.php 
 -- Role.php

- **MIGRATION FILES** (database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\27\155312\create\roles\table.php
 -- 2019\09\27\164342\create\role\user\table.php

- **MODEL FACTORY FILES** (database/factories/)
 -- UserFactory.php 
 -- RoleFactory.php

- **UNIT TEST FILES** (tests/Units/)
 -- UserTest.php 
 -- RolesTest.php

4. Has One Through Relationship

The “has-one-through” relationship links models through a single intermediate relation.

Scenario:

Given a Supplier has one User , and each user is associated with a user History record, the supplier model may access the user’s history through the intermediate user model.

hasOneThrough()

— A supplier has one history through a user
— has no official INVERSE relationship.



// App/Supplier.php
...
public function userHistory() 
{ 
 return $this-\>hasOneThrough(History::class, User::class); 
}

The “ hasThrough ” relationships do not have official reverse relationship since the concerned models are always indirectly related but a reverse can be hacked by linking through the intermediate model like below, however, beware of n+1 issues and eager load as appropriate.:



// App/History.php
...
/** 
 * With this attribute defined it can be used as **$this-\>supplier**
 */
public function getSupplierAttribute()
{
 return $this-\>user-\>supplier;
}

Files relevant to this test 👇



- **MODEL FILES** (App/)
 -- User.php 
 -- Supplier.php
 -- History.php

- **MIGRATION FILES** (database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\27\155312\create\roles\table.php
 -- 2019\09\27\164342\create\role\user\table.php

- **MODEL FACTORY FILES** (database/factories/)
 -- UserFactory.php 
 -- SuppliersFactory.php
 -- HistoryFactory.php

- **UNIT TEST FILES** (tests/Units/)
 -- UserTest.php 
 -- SuppliersTest.php
 -- HistoriesTest.php

5. Has Many Through Relationship

Just like the “has-one-through” relationship links a distant related model through an intermediate relation, “ has-many-through” does same but it can reference many instances of the distant related model.

Scenario:

A Country model might have many Post models through an intermediate User model. We will write a test that ensures blog posts for a given country can be accessed on the country instance by a hasManyThrough relationship.

hasManyThrough()

— A country can have many posts through a user model
— has no official REVERSE relationship



// App/Country.php
...
public function posts() 
{ 
 return $this-\>hasManyThrough(Post::class, User::class); 
}

NB: We now make use of a parent::setup() method to DRY the test codes.

The “ hasThrough ” relationships do not have official reverse relationship but a reverse can be hacked by linking through the intermediate model like below, (beware of n+1 issues and eager load as appropriate):



// App/Post.php
...
/** 
 * With this attribute defined it can be used as **$this-\>country**
 */
public function getCountryAttribute()
{
 return $this-\>user-\>country;
}

Files relevant to this test 👇



- **MODEL FILES** (App/)
 -- User.php 
 -- Country.php
 -- Post.php

- **MIGRATION FILES** (database/migrations/)
 -- 2014\10\12\000000\create\users\table.php
 -- 2019\09\27\100604\create\posts\table.php
 -- 2019\09\28\130218\create\countries\table.php
 -- 2019\09\28\131328\add\country\id\to\users\table.php

- **MODEL FACTORY FILES** (database/factories/)
 -- UserFactory.php 
 -- CountryFactory.php
 -- PostFactory.php

- **UNIT TEST FILES** (tests/Units/)
 -- UserTest.php 
 -- CountriesTest.php
 -- PostsTest.php

See the polymorphic relationship tests in the next post.

👉Part 1: Intro and Schema Tests
⏯Part 2: Testing Basic Model Relationships
👉Part 3: Testing Polymorphic Relationships

Part 1: Testing Model Relationships in Laravel — Schema Tests

tony — Sun, 29 Sep 2019 16:13:24 +0000

Part 1: Testing Model Relationships in Laravel — Schema Tests

Laravel Database Designer — Biodesign.cc

Laravel makes TDD a lot more fun, it is such a joy to work with . The essence of the tests in this series is to ensure that your app model relationship is not missing a bolt. The code snippets will be available for easy reach at this Github project link.

To make this post more organized it will be split into three (3) parts.

Part 1: Intro and Schema Tests ⏯
Part 2: Testing Basic Model Relationships
Part 3: Testing Polymorphic Relationships

Writing tests make your code rock solid, predictable and highly maintainable. I have written some terrible apps in the past and it can be unnerving when broken codes scream in — y o u r — face. Those years I had no clue about unit tests — fix one bug and another one surfaces, more annoying is that you don’t know when another will pop up. Errors are bound to occur if relevant models are missing or wrongly connected.

Unit and Feature Tests

Unit Tests are written for small pieces of a code base such as methods or attributes in a class. It usually deals with testing fine details at low level only. In our case we will be testing some methods on Laravel model classes, that is, model connections and relationships between different parts of an app.

Feature Tests is more encompassing as it sums up different part of a code and tests how well they inter-operate eg functional tests and integration tests on components, modules etc. We are not going into functional test in this post.

NB: it is assumed that you have a working knowledge of Laravel, therefore nitty gritty of installation, eloquent model setup and relationship are not discussed. However, test relevant topics will be discussed in depth.

To install a new laravel app :

laravel new modelRelTests via installer
composer create-project --prefer-dist laravel/laravel modelRelTests via create-project

1. Set Up Test Suite

We are going to make use of an sqlite database and use it in memory for faster test runs. Go to phpunit.xml at the root directory of your application and add:

...
<server name=" **DB\_CONNECTION**" value=" **sqlite**"/>
<server name=" **DB\_DATABASE**" value=" **:memory:**"/>

2. Creating a Test Class

If we run vendor/bin/phpunit at this point we get 2 tests for the dummy tests added by Laravel, one test each in the Unit and Feature test directories. Seeing the green is refreshing. You should delete the two files in preparation for our real tests.

By default, every new Laravel installation comes with a User model class (along with migration, controller etc) but not a test. We should create our own test file with the command:

php artisan make:test **UserTest --unit**

This creates a test file named UserTest.php within the tests/Unit directory in the root folder. The --unit flag implies that we are creating a unit test and should add the generated file to the unit test directory. Without the --unit flag we have a feature test and it gets added to tests/Feature directory.

3. Schema Test — My First Test in Every Model

Before visiting model relationship tests, my very first unit test in every Laravel model is the schema test. We can use this test to ensure that relevant table columns are not missing and also have the correct and expected names. All we need to do is this:

Take note of :

use Illuminate\Support\Facades\Schema; namespace.
RefreshDatabase and WithFaker traits. These two traits are important in most tests since you will most likely need a database of data to test your models and the faker library to populate a database with data to be tested upon.

If you want to be explicit about your schema checks you may check each individual field with:

...Schema:: **hasColumn** ('model', **'column'** ), 1); instead of
...Schema:: **hasColumns** ('model', **['column\_1', 'column\_2']**), 1); which checks all columns existence at once.

I prefer **hasColumns()** though, odd part is that you get a general error report and so don’t know the actual column affected unless you check thoroughly.

Run vendor/bin/phpunit and see the result below 👇

TDD — failed because database is not set

This test failed, why? We have not set up or created our database yet. Set up your database configurations within the .env file according to your machine. See the snippet below:

DB\_DATABASE=homestead
DB\_USERNAME=homestead
DB\_PASSWORD=secret

Then, create your database within your xampp, wamp or homestead and run:

$ php artisan migrate

Illuminate\Database\QueryException : SQLSTATE[42000]: If you encounter the Illuminate\Database\QueryException : SQLSTATE[42000] error while running the migration like in image below

Illuminate\Database\QueryException

Go to App/Providers/AppServiceProvider.php and make the following updates. Within the boot method add Schema::defaultStringLength(191); and add a the namespace like so use Illuminate\Support\Facades\Schema;. See below 👇

Fix Illuminate\Database\QueryException : SQLSTATE[42000] error.

Run vendor/bin/phpunit again and you should get a success result as below:

Test Result Successful!

Play around a little more by adding a new column into the test, do not add to the schema migration file initially, run the test to see results, failed? Make it pass. This particular test may look boring but from the ground up you can be sure your schema integrity is accounted for.

4. Creating Aliases for Your CLI Commands

Now that you are beginning to write tests there will be a lot of tests to run. It would make much sense to have shortcut form of some lengthy commands, the cli commands you use often. This will surely improve your productivity. Bash alias es to the rescue, it is a method of supplementing or overriding Bash commands with new ones eg allow users to customize their experience in a POSIX terminal.

alias name="command to shorten" — creates a new alias ‘name’ NB: there are no spaces around the = sign.
alias — displays all your set aliases directly in the CLI.
On a Windows PC, you may access and manage a list of your set aliases in the .bash_profile file at C:\Users\yourUsername\.bash\_profile. Here you can add, update or remove the entries.

I use the commands below most times in my tests:

pu vendor/bin/phpunit this runs all tests within the tests directory.
puf vendor/bin/phpunit --filter this selectively runs test within all files and test methods whose name has the string (pattern).
putu vendor/bin/phpunit --testsuite Unit this runs all tests within the Test\Units directory only.
putf vendor/bin/phpunit --testsuite Feature this runs all tests within the Test\Features directory only.

There are more others but these ones comes handy for me all the time.

Conclusion

I become paranoid if I write an app without some tests these days. I learnt the hard way and has since inculcate the habit of writing comprehensive tests for my apps — the predictability, ease of maintenance and confidence that accompanies a well tested codebase is indescribable. Kindly check the remaining two parts (see links below 👇) for they are the biggest deal.

⏯Part 1: Intro and Schema Tests
👉Part 2: Testing Basic Model Relationships
👉Part 3: Testing Polymorphic Relationships

Your comments are highly appreciated.

SEO for Web Developers — To Use JSON-LD or Microdata?

tony — Wed, 11 Sep 2019 19:57:24 +0000

— Structured Data

Image Source: Wordlift

What is Structured Data in SEO?

While Structured data simply refers to any data which is organized or “given structure”, it can be implemented as an on-page markup that enable search engines to better understand the information available on a given web page, and then use this information to improve search results listing. It can be implemented on a website using Microdata, JSON-LD or RDFa schema types. Structured data is both Technical and On-page SEO but discussed often under Technical SEO.

Structured data is an onpage SEO because it is implemented within a website unlike off-page (off-site) SEO that deals with optimizations taking place from sources external to the target website eg link building, social media & influencer marketing, guest blogging, etc. On-page SEO determines how a page is displayed on web apps and on S earch E ngine R esult P age s ( SERP s) eg link previews, sitelink search boxes, rich card snippets, knowledge graph panels and many other enhanced snippets.

Schema is a way to label or organize your content so that search engines have a better understanding of what certain elements on your web pages are. This code provides structure to your data, which is why schema is often referred to as “structured data.” — Moz Pro.

Search engine juggernauts such as Google, Bing, and other online search companies came together to standardize and develop schema markup in the project maintained at schema.org, they however have contrasting preferences. Google have preference for JSON-LD while Bing’s preferred markup type is the Microdata format (Bing now support JSON-LD). Both technologies are quite popular and help in enhancing webpages for search engine data mining. We shall compare the pros and cons of each based on usability, portability, maintainability, etc. RDFa and Microdata are semantically similar thus the discussion about Microdata in this article also applies to RDFa (which is less popular).

A related but standardized online repository of structured data for notable entities is the Wikimedia’s Wikidata.org. Wikidata feeds search engines with well-defined structured data about important topics.

What is Microdata?

Microdata is a WHATWG HTML specification used to nest metadata within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users — Wikipedia.

Microdata markup is grudgingly inline and clings tightly to HTML tags as additional attributes in the HTML markup code. See an example from wikipedia below:

Pros of Microdata✨

Supported by all major search engines.
The semantic annotations appear very close to the human-readable information.
More trustable as inline semantic markup may not be providing misleading information since the values are often directly associated with actual texts on the web page.
Easier to mark up pages by directly plugging in variables into the relevant sections after markup structure is set during development.

Cons of Microdata🤦

Hard to maintain : Need lot of developer work and designer changes. It is hard to troubleshoot without touching the page HTML code and inline semantic markup can break very easily.
Not Tidy : Additional attributes such as itemscope, itemtype, itemprop etc are known to clog up entire page as they are sandwiched within every HTML tag. This makes page structure look bloated and untidy.
Not as Feasible in CMS Sites : To add microdata to an existing website the page HTML markup may have to be rewritten every time. CMSes (eg Wix, Wordpress) are ready-made and will present much hassle to mark up 😒.
Verbose and Repetitive : The additional attribute mentioned earlier does accompany every semantic declarations and contributes unnecessary repetitive texts to page structure and content.

What is JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) is a method of implementing structured data markup on a website. It is supported by Google, Bing, Yandex, and many smaller search engines. JSON-LD utilizes JSON notation. The Microdata markup page content above can be rewritten with JSON-LD as:

Pros of JSON-LD✨

The syntax is relatively simpler, easy to write and troubleshoot.
The block of JSON-LD markup (semantic layer) is decoupled from the page’s HTML markup (representation layer). This separation of concerns give total flexibility and improves site maintainability.
It is CMS friendly (eg Wix, Wordpress). A JSON-LD code block can be used to mark up existing web pages more easily. It entails to slotting the code into head or body section. With Wordpress, the code can be added with plugins while on Wix, it can be pasted into the New Tool field in the settings area of a Wix account.
Like Microdata and RDFa, JSON-LD can be placed in the body of the page, but can also be used in the head.

Cons of JSON-LD🤦

It is more difficult for search engines to verify that the JSON-LD structured data is consistent with the actual text information on the webpage and that the JSON-LD data does not contain misleading information
The block of JSON-LD does not appear alongside the human-readable information, some browsers may not easily display contextual hyperlinks in close proximity to the annotated content — W3.org.
Not earlier supported by Bing, this is no more an issue.

Structured Data on A Dynamic Website

Microdata On A Dynamic Website

An example snippet of what a Microdata markup could look like on dynamic webpage. It does the job but still retains the bloated markup look, the HTML markup looks busy.

JSON-LD On A Dynamic Website

Gone are the days when Javascript’s DOM-rendered contents don’t work quite well with web crawlers, with the advance in technology it is now a no issue. By changing the previous example a little bit we can have data coming from a database and parsed with javascript as seen in the jsfiddle example below:

Viewing all the pages we mark up in this post on Google Structured Data Testing Tool, the result will be:

Rendered result of all markup types in Google Structured Data Testing Tool .

With a dynamic website the supplied data will vary based on the page being viewed. The API feeding the schema code is expected to send the appropriate variables used in generating expected markup for each individual page.

There is a reason why separation of concerns is the norm in everything that has to do with a programmer’s activities. For a web developer, it starts with externalizing page assets such as stylesheets and javascript code. Even in any code writing process, you are expected to decouple your code and refactor into reusable units or methods as much as possible. The same is desirable when handling SEO schema markup to ensure code reusability and improvement of site maintainability. This separation of concern is only possible with JSON-LD.

Conclusion

Both Microdata and JSON-LD gets the job done and can be tested with various online testing tools and still yield exactly same result. However, JSON-LD shines. With it a website SEO maintenance is painless and ensures no interference with page HTML markup, this is a big win 💪. Chances are you are to optimize an old website or any of the third party CMS after it was originally published. Using Microdata in this scenario is next to impossible unless you restructure the HTML code base.

Either of the two can be your preferred choice depending on the scenario, they both get the job done.

Does these stuffs really work?

See my next SEO post on how I have recorded 100% knowledge panel generation for indie music artistes using advanced combination of publicly available data to construct an artiste’s knowledge graph. The result makes it easy for Google bots to easily generate a panel for all of them.

Forem: tony

Laravel on Steroids! Get 10x Speed in Your App Development

- DB-MVCr-MPR-TA

Part 3: Testing Model Relationships in Laravel — POLYMORPHIC

Part 3: Testing Model Relationships in Laravel — POLYMORPHIC

POLYMORPHIC RELATIONSHIPS

1. One-to-One Polymorphic Relationship

Scenario:

morphTo()

morphOne()

2. One-to-Many (Polymorphic)

Scenario:

morphTo()

morphMany()

Many-to-Many (Polymorphic)

Kindly check back soon

Part 2: Testing Model Relationships in Laravel — BASIC

Part 2: Testing Model Relationships in Laravel — BASIC

THE RELATIONSHIPS

1. One To One Relationship

Scenario:

hasOne()

belongsTo()

2. One To Many Relationship

Scenario:

hasMany()

belongsTo()

Heads up:

3. Many-to-Many Relationship

Scenario:

belongsToMany()

belongsToMany()

4. Has One Through Relationship

Scenario:

hasOneThrough()

5. Has Many Through Relationship

Scenario:

hasManyThrough()

Part 1: Testing Model Relationships in Laravel — Schema Tests

Part 1: Testing Model Relationships in Laravel — Schema Tests

Table of contents

Unit and Feature Tests

1. Set Up Test Suite

2. Creating a Test Class

3. Schema Test — My First Test in Every Model

4. Creating Aliases for Your CLI Commands

Conclusion

SEO for Web Developers — To Use JSON-LD or Microdata?

— Structured Data

What is Structured Data in SEO?

What is Microdata?

Pros of Microdata✨

Cons of Microdata🤦

What is JSON-LD?

Pros of JSON-LD✨

Cons of JSON-LD🤦

Structured Data on A Dynamic Website

Microdata On A Dynamic Website

JSON-LD On A Dynamic Website

Conclusion

Does these stuffs really work?