diff --git a/README.md b/README.md
index 77e8072..7cbbba5 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,7 @@
# Mage-OS Documentation
+[TOC]
+
You can find the online version of the Mage-OS documentation at [https://devdocs.mage-os.org/](https://devdocs.mage-os.org)
## Markup and Features
diff --git a/acl-xml.md b/acl-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/acl_xml.md b/acl_xml.md
new file mode 100644
index 0000000..c9c53fc
--- /dev/null
+++ b/acl_xml.md
@@ -0,0 +1,100 @@
+# `acl.xml` Reference Documentation
+
+[TOC]
+
+This reference documentation provides information on the structure and usage of the `acl.xml` file in Magento 2.
+`acl.xml` is an essential configuration file used to define Access Control List (ACL) permissions for various
+resources in your Magento 2 module or extension.
+
+## Introduction
+
+Access Control List (ACL) is a security mechanism used to control access to resources based on user roles and
+permissions. The `acl.xml` file is used in Magento 2 to define these roles, resources, and associated permissions for
+your module or extension.
+
+## Structure of `acl.xml`
+
+The `acl.xml` file follows a specific structure and should be placed in the `etc` directory of your module or extension.
+Here is an example of the basic structure of `acl.xml`:
+
+```xml
+
+
+
+
+
+```
+
+The `xmlns:xsi` and `xsi:noNamespaceSchemaLocation` attributes define the XML schema for validation. The `` tag is
+the root element, under which you define resources and roles.
+
+## Defining Resources and Roles
+
+In the `` tag, you define `` and `` elements to specify the resources and roles respectively. A
+resource represents a specific functionality or area in your module or extension, while a role represents a user role or
+group.
+
+Here is an example of defining a resource and a role in `acl.xml`:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+In the above example, the `` element defines a resource with an `id`, `title`, and `sortOrder`. The `id`
+should follow the format `::`. Similarly, the `` element defines a role with
+an `id`, `title`, and `sortOrder`.
+
+## Applying ACL Permissions
+
+Once you have defined resources and roles, you need to specify the permissions or access rules for each role on the
+respective resources. For this, you use the `` and `` elements.
+
+Here is an example of applying ACL permissions in `acl.xml`:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+In the above example, the `` element is nested under the appropriate `` and ``. The `id`
+attribute follows the format `::`. The `title` attribute provides a human-readable
+title for the permission.
+
+## Conclusion
+
+The `acl.xml` file is a crucial configuration file in Magento 2 for defining Access Control List (ACL) permissions. By
+understanding its structure and usage, you can control access to resources based on user roles and permissions
+effectively.
diff --git a/api-reference.md b/api-reference.md
index e69de29..8d60a00 100644
--- a/api-reference.md
+++ b/api-reference.md
@@ -0,0 +1,148 @@
+# API Reference Documentation
+
+[TOC]
+
+## Introduction
+
+Welcome to the API Reference Documentation for the Magento 2 API. This comprehensive guide will provide you with all the
+necessary information to interact with the Magento 2 API programmatically using PHP.
+
+## Prerequisites
+
+Before you start using the Magento 2 API, make sure you have the following prerequisites:
+
+- Basic knowledge of PHP programming language
+- Familiarity with Magento 2 architecture and concepts
+- Access to a Magento 2 installation with API access enabled
+
+## API Basics
+
+Magento 2 provides a powerful API that allows you to interact with various aspects of the system, including customers,
+products, orders, and more. The API is implemented using the Representational State Transfer (REST) architectural style
+and is designed to be platform-agnostic.
+
+To authenticate and interact with the API, you need to obtain an access token, which acts as a credential to
+authenticate your requests. You can obtain an access token by authenticating with the Magento 2 OAuth server using your
+credentials. Once you have the access token, you can use it to make authorized requests to the API.
+
+## API Endpoints
+
+The Magento 2 API is organized into several endpoints, each representing a different aspect of the system. The endpoints
+provide a set of resources and operations that you can use to manipulate and retrieve data.
+
+Here are some of the main API endpoints available in Magento 2:
+
+### Customers
+
+The Customers API endpoint allows you to manage customer-related information, such as creating new customers, retrieving
+customer details, updating customer information, and more.
+
+```php
+// Example: Retrieve customer details
+GET /rest/V1/customers/{customerId}
+```
+
+### Products
+
+The Products API endpoint provides methods to manage product-related data, such as creating new products, retrieving
+product information, updating product attributes, and more.
+
+```php
+// Example: Create a new product
+POST /rest/V1/products
+```
+
+### Orders
+
+The Orders API endpoint allows you to manage orders in Magento 2, including creating new orders, retrieving order
+details, updating order status, and more.
+
+```php
+// Example: Retrieve order details
+GET /rest/V1/orders/{orderId}
+```
+
+### Carts
+
+The Carts API endpoint provides methods to manage shopping carts, including creating new carts, adding products to a
+cart, retrieving cart details, and more.
+
+```php
+// Example: Create a new cart
+POST /rest/V1/carts/mine
+```
+
+## Making API Requests
+
+To make API requests, you can use any HTTP client library that supports sending HTTP requests. In PHP, you can use
+libraries such as Guzzle, cURL, or the built-in `file_get_contents()` function.
+
+Here's an example of making a GET request to retrieve customer details using the Guzzle HTTP client library:
+
+```php
+request('GET', 'https://example.com/rest/V1/customers/1', [
+ 'headers' => [
+ 'Authorization' => 'Bearer {access_token}',
+ 'Content-Type' => 'application/json',
+ ],
+]);
+
+// Get the response body
+$body = $response->getBody();
+
+// Process the response data
+$customer = json_decode($body, true);
+
+// Print the customer details
+echo "Customer Name: " . $customer['firstname'] . " " . $customer['lastname'];
+```
+
+## Error Handling
+
+When interacting with the Magento 2 API, it's important to handle errors properly. The API returns meaningful error
+messages and HTTP status codes to indicate the success or failure of a request.
+
+Here's an example of handling errors when retrieving customer details:
+
+```php
+// Make a GET request to retrieve customer details
+try {
+ $response = $client->request('GET', 'https://example.com/rest/V1/customers/1', [
+ 'headers' => [
+ 'Authorization' => 'Bearer {access_token}',
+ 'Content-Type' => 'application/json',
+ ],
+ ]);
+
+ // Get the response body
+ $body = $response->getBody();
+
+ // Process the response data
+ $customer = json_decode($body, true);
+
+ // Print the customer details
+ echo "Customer Name: " . $customer['firstname'] . " " . $customer['lastname'];
+} catch (\GuzzleHttp\Exception\RequestException $e) {
+ // Handle request exceptions (e.g., connection errors, server errors, etc.)
+ echo "Request Exception: " . $e->getMessage();
+} catch (\Exception $e) {
+ // Handle other exceptions
+ echo "Exception: " . $e->getMessage();
+}
+```
+
+## Conclusion
+
+Congratulations! You now have a solid understanding of the Magento 2 API and how to interact with it using PHP. Refer to
+the API documentation for further details on available endpoints, request/response formats, and additional
+functionality.
+
+Happy coding!
diff --git a/basic-configuration.md b/basic-configuration.md
index cc15f98..ba66ec2 100644
--- a/basic-configuration.md
+++ b/basic-configuration.md
@@ -1,84 +1,121 @@
-# Basic Configuration in Magento 2
-
-- [Global Configuration: env.php](#global-configuration-env.php)
-- [Application Configuration: config.php](#application-configuration-config.php)
-- [Module Configuration: config.xml](#module-configuration-config.xml)
-
-Magento 2, a highly flexible PHP-based e-commerce framework, provides a wealth of configuration options that allow you
-to tailor your e-commerce platform precisely to your needs. This guide aims to provide you with a comprehensive
-understanding of Magento 2's basic configuration.
-
-## Global Configuration: env.php
-
-Magento's global configuration is located in the `app/etc/env.php` file. This file contains settings that apply to the
-entire Magento application, such as backend frontname, install date, crypt key, session save location, and more.
-
-### Example
-
-```php
-return [
- 'backend' =>
- [
- 'frontName' => 'admin',
- ],
- 'install' =>
- [
- 'date' => 'Fri, 25 Jun 2023 19:25:14 +0000',
- ],
- // ...
-];
-```
-
-In the above example, `'frontName' => 'admin'`, is the URL segment for the admin panel.
-
-## Application Configuration: config.php
-
-Magento's `config.php` file is located in the same directory as `env.php` (`app/etc/`). This file is responsible for
-managing the list of installed modules and their `enable/disable` status.
-
-```php
-return [
- 'modules' => [
- 'Magento_Store' => 1,
- 'Magento_AdminNotification' => 1,
- //...
- ],
-];
-```
-
-In this configuration, `'Magento_Store'` and `'Magento_AdminNotification'` modules are enabled as indicated by `'1'`.
-If a module is disabled, it would be indicated by `'0'`.
-
-## Module Configuration: config.xml
-
-Each module in Magento 2 has its own `config.xml` file which is found in the `etc` directory of the respective module.
-This file is used to manage module-specific configurations, such as default values for the module's settings.
-
-### Example
-
-Let's take a look at an example configuration in a `config.xml` file:
-
-```xml
-
-
-
-
-
- 12
-
-
-
-
-```
-
-In this example, we have the `12` configuration inside the `` path.
-This particular setting dictates the default number of products displayed per page on the product list.
-
-Remember: After modifying a module's `config.xml file`, it's necessary to clear Magento's cache (System > Tools > Cache
-Management) to apply the changes.
-
-Before adjusting these configurations, remember that they can significantly impact your application's functionality and
-behavior. It's highly recommended that you have a thorough understanding of Magento 2's architecture and always test
-these changes in a development or staging environment before applying them to a live store. This ensures stability and
-can prevent unintended effects on the end-user experience.
+# Basic Configuration Documentation
+
+[TOC]
+
+This document provides instructions on how to perform basic configuration in Magento 2. Magento 2 is a powerful
+e-commerce platform built on PHP, and understanding how to configure it is essential for creating a successful online
+store. In this guide, we will cover the most important configuration settings and provide concrete examples and code
+snippets to help you understand and implement them.
+
+## System Configuration
+
+The system configuration in Magento 2 allows you to set up and manage various aspects of your e-commerce store.
+
+To access the system configuration, follow these steps:
+
+1. Log in to the Magento 2 admin panel.
+2. Navigate to **Stores** > **Configuration**.
+
+### Example: Changing the Base URL
+
+One of the most crucial system configuration settings is the Base URL. This setting determines the URL that customers
+will use to access your store.
+
+To change the Base URL:
+
+1. Go to **Stores** > **Configuration**.
+2. In the left-hand menu, click on **General** > **Web**.
+3. Expand the **Base URLs (Secure)** or **Base URLs (Unsecure)** section, depending on your requirements.
+4. Enter the desired URL in the **Base URL** field.
+5. Click on **Save Config**.
+
+## Store Configuration
+
+Store configuration settings in Magento 2 allow you to customize various aspects related to your store's appearance and
+functionality.
+
+To access the store configuration, follow these steps:
+
+1. Log in to the Magento 2 admin panel.
+2. Navigate to **Stores** > **Configuration**.
+
+### Example: Changing the Store Name
+
+The store name is displayed prominently on your website and should reflect your brand and business.
+
+To change the store name:
+
+1. Go to **Stores** > **Configuration**.
+2. In the left-hand menu, click on **General** > **Store Information**.
+3. Enter the desired store name in the **Store Name** field.
+4. Click on **Save Config**.
+
+## Catalog Configuration
+
+Catalog configuration settings in Magento 2 allow you to manage how your products are displayed, categorized, and
+priced.
+
+To access the catalog configuration, follow these steps:
+
+1. Log in to the Magento 2 admin panel.
+2. Navigate to **Stores** > **Configuration**.
+
+### Example: Setting Up Product Categories
+
+Product categories help customers navigate your store and find the products they are looking for. To set up product
+categories:
+
+1. Go to **Stores** > **Configuration**.
+2. In the left-hand menu, click on **Catalog** > **Catalog**.
+3. Expand the **Category Top Navigation** section.
+4. Enable the **Enable Category Top Navigation Menu** option.
+5. Click on **Save Config**.
+
+## Payment Configuration
+
+Payment configuration settings in Magento 2 allow you to set up and manage the payment methods available to your
+customers.
+
+To access the payment configuration, follow these steps:
+
+1. Log in to the Magento 2 admin panel.
+2. Navigate to **Stores** > **Configuration**.
+
+### Example: Enabling PayPal Express Checkout
+
+PayPal Express Checkout is a popular payment method. To enable PayPal Express Checkout:
+
+1. Go to **Stores** > **Configuration**.
+2. In the left-hand menu, click on **Sales** > **Payment Methods**.
+3. Expand the **PayPal Express Checkout** section.
+4. Set the **Enabled** option to **Yes**.
+5. Enter your PayPal API credentials in the appropriate fields.
+6. Click on **Save Config**.
+
+## Shipping Configuration
+
+Shipping configuration settings in Magento 2 allow you to manage how shipping is calculated and handled in your store.
+
+To access the shipping configuration, follow these steps:
+
+1. Log in to the Magento 2 admin panel.
+2. Navigate to **Stores** > **Configuration**.
+
+### Example: Configuring Flat Rate Shipping
+
+Flat rate shipping charges a fixed rate for shipping regardless of the order's weight or location. To configure flat
+rate shipping:
+
+1. Go to **Stores** > **Configuration**.
+2. In the left-hand menu, click on **Sales** > **Shipping Methods**.
+3. Expand the **Flat Rate** section.
+4. Set the **Enabled** option to **Yes**.
+5. Configure the **Title**, **Method Name**, **Price**, and other relevant fields.
+6. Click on **Save Config**.
+
+## Conclusion
+
+In this documentation, we have covered the basic configuration settings in Magento 2, including system, store, catalog,
+payment, and shipping configurations. By following the provided instructions and using the code snippets and examples,
+you can easily configure your Magento 2 store to meet your specific requirements. For more advanced configuration
+options, refer to the official Magento 2 documentation or consult with a Magento developer.
diff --git a/best-practices-for-extension-development.md b/best-practices-for-extension-development.md
index e69de29..7c63cbe 100644
--- a/best-practices-for-extension-development.md
+++ b/best-practices-for-extension-development.md
@@ -0,0 +1,290 @@
+# Best Practices for Extension Development
+
+[TOC]
+
+This documentation provides a comprehensive guide on best practices for developing extensions in Magento 2. Following
+these guidelines will ensure that your extensions are efficient, secure, and compatible with future versions of Magento.
+
+## Directory Structure
+
+Organizing your extension's files properly is crucial for maintainability. Follow the recommended directory structure
+provided by Magento to ensure consistency across projects.
+
+Here's a typical directory structure for a Magento 2 extension:
+
+```
+├── app
+│ └── code
+│ └── VendorName
+│ └── ModuleName
+│ ├── Block
+│ ├── Controller
+│ ├── etc
+│ ├── Helper
+│ ├── Model
+│ ├── Observer
+│ ├── Plugin
+│ ├── Setup
+│ ├── Ui
+│ └── view
+└── ...
+```
+
+## Extension Naming
+
+Choose a unique, descriptive name for your extension to avoid conflicts with other extensions. Magento recommends using
+the following format for naming your extension: `VendorName_ModuleName`.
+
+For example, if your extension is related to a payment gateway named "FastPay" and your company name is "Acme", you
+could name your extension `Acme_FastPay`.
+
+## Module Registration
+
+To register your extension with Magento, create a `registration.php` file in the root directory of your extension. This
+file should contain a registration callback function that returns an array with the module's name and version.
+
+Here's an example of a `registration.php` file:
+
+```php
+
+
+Magento 2 heavily utilizes dependency injection to manage object dependencies. Follow the dependency inversion principle
+and inject dependencies through constructors or setter methods.
+
+Avoid instantiating objects directly using the `new` keyword within your extension. Instead, rely on Magento's
+dependency injection framework to provide necessary dependencies.
+
+Here's an example of how to inject a dependency in a constructor:
+
+```php
+gateway = $gateway;
+ }
+}
+```
+
+## Event Observers
+
+Magento 2 provides a robust event system that allows extensions to observe and modify the behavior of the core system.
+Leverage event observers to extend or customize Magento functionality.
+
+To create an event observer, you need to define the event you want to observe in your extension's `events.xml` file, and
+then create a corresponding observer class.
+
+Here's an example of an `events.xml` file:
+
+```xml
+
+
+
+
+
+
+```
+
+And here's an example of an observer class:
+
+```php
+
+
+Provide a user-friendly configuration interface for your extension using the `system.xml` file. This file defines the
+configuration fields and sections that appear in the admin panel.
+
+Here's an example of a `system.xml` file:
+
+```xml
+
+
+
+
+
+
+
+
+ acme
+ Acme_FastPay::config
+
+
+
+
+ Magento\Config\Model\Config\Source\Yesno
+
+
+
+
+
+
+```
+
+## Database Schema and Setup
+
+If your extension requires additional database tables or changes to existing tables, follow Magento's recommended
+approach for managing database schema and setup.
+
+Create a `db_schema.xml` file to define your extension's database schema. Within this file, you can define tables,
+columns, indexes, and other database elements.
+
+Here's an example of a `db_schema.xml` file:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+```
+
+To handle database setup and versioning, create an `InstallSchema.php` file in your extension's `Setup` directory. This
+file should contain the necessary logic to create or update your extension's database schema.
+
+Here's an example of an `InstallSchema.php` file:
+
+```php
+startSetup();
+
+ // Add database schema setup logic here
+
+ $installer->endSetup();
+ }
+}
+```
+
+## Code Quality
+
+Writing clean and well-documented code is essential for maintainability and collaboration. Follow these best practices
+to ensure high code quality:
+
+- Follow the [PSR-12 coding style](https://www.php-fig.org/psr/psr-12/) for PHP code.
+- Use meaningful variable and function names to improve readability.
+- Add inline comments to explain complex or important sections of code.
+- Write PHPDoc comments for classes, methods, and properties to provide clear documentation.
+
+## Unit Testing
+
+Writing unit tests for your extension is crucial to ensure its stability and reliability. Magento provides a robust
+testing framework based on PHPUnit.
+
+Create test classes for your extension using the `Test` directory structure. Test classes should be namespaced under the
+extension's namespace with the `Test\Unit` suffix.
+
+Here's an example of a test class for a payment gateway extension:
+
+```php
+objectManager = new ObjectManager($this);
+
+ $this->payment = $this->objectManager->getObject(
+ Payment::class,
+ [
+ // Inject dependencies here
+ ]
+ );
+ }
+
+ public function testExample()
+ {
+ // Write your unit tests here
+ }
+}
+```
+
+## Security Considerations
+
+Ensure the security of your extension by following these best practices:
+
+- Validate and sanitize all user inputs to prevent security vulnerabilities such as SQL injection and cross-site
+ scripting.
+- Use Magento's built-in security features, such as CSRF protection and form key validation, when handling sensitive
+ operations or user data.
+- Regularly update your extension to address any security vulnerabilities discovered in dependencies or Magento itself.
+- Stay informed about Magento's security practices and guidelines by regularly checking their official documentation and
+ security advisories.
+
+## Compatibility
+
+Maintaining compatibility with different versions of Magento is crucial for the longevity and adoption of your
+extension. Follow these guidelines to ensure compatibility:
+
+- Keep up-to-date with Magento's latest releases and features to leverage new functionality.
+- Avoid using deprecated Magento features or methods.
+- Test your extension across different versions of Magento to identify and resolve compatibility issues.
+- Clearly communicate the supported Magento versions in your extension's documentation and release notes.
+
+By adhering to these best practices, you can develop high-quality Magento 2 extensions that are secure, efficient, and
+compatible across different versions of Magento.
diff --git a/best-practices-for-secure-development.md b/best-practices-for-secure-development.md
index e69de29..4520dbd 100644
--- a/best-practices-for-secure-development.md
+++ b/best-practices-for-secure-development.md
@@ -0,0 +1,135 @@
+# Best Practices for Secure Development
+
+[TOC]
+
+In today's digital landscape, security is of paramount importance. As a developer, it is essential to incorporate secure
+practices into your development process to protect sensitive data and prevent unauthorized access to your applications.
+This guide will outline best practices for secure development, specifically focusing on PHP and Magento 2.
+
+## Input Validation and Sanitization
+
+One common vulnerability in web applications is insufficient input validation and sanitization. Attackers can exploit
+this weakness by injecting malicious code or performing various types of attacks such as SQL injection or cross-site
+scripting (XSS). To mitigate these risks, always validate and sanitize user inputs before using them in your
+application.
+
+### Example: Input Validation in PHP
+
+```php
+$email = $_POST['email'];
+
+if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
+ // Valid email address, proceed with further processing
+} else {
+ // Invalid email address, handle the error appropriately
+}
+```
+
+### Example: Input Sanitization in Magento 2
+
+```php
+$productId = $this->getRequest()->getParam('id');
+
+$sanitizedProductId = $this->filterManager->sanitize($productId);
+```
+
+## Secure Authentication and Authorization
+
+Proper authentication and authorization mechanisms are crucial to prevent unauthorized access to sensitive data and
+functionalities within your application. Always use strong and unique passwords, implement secure password storage using
+hashing algorithms, and enforce multi-factor authentication where appropriate. Additionally, ensure that users are
+authorized to access specific resources or perform certain actions based on their roles and privileges.
+
+### Example: Secure Password Storage in PHP
+
+```php
+$password = $_POST['password'];
+
+$hashedPassword = password_hash($password, PASSWORD_DEFAULT);
+```
+
+### Example: Authorization in Magento 2
+
+```php
+if ($this->_authorization->isAllowed('Namespace_Module::resource')) {
+ // Authorized, proceed with the requested action
+} else {
+ // Unauthorized, handle the error appropriately
+}
+```
+
+## Protection against Cross-Site Scripting (XSS) Attacks
+
+Cross-Site Scripting (XSS) attacks occur when an attacker injects malicious scripts into web pages viewed by other
+users. These scripts can then steal sensitive information, manipulate website content, or perform other malicious
+activities. To prevent XSS attacks, always sanitize user-generated content and encode it properly when outputting it
+into web pages.
+
+### Example: XSS Prevention in PHP
+
+```php
+$userInput = $_POST['message'];
+
+$cleanInput = htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');
+```
+
+### Example: XSS Prevention in Magento 2
+
+```php
+$customerName = $this->escaper->escapeHtml($customer->getName());
+```
+
+## Protection against SQL Injection Attacks
+
+SQL Injection attacks occur when an attacker injects malicious SQL statements into queries executed by an application's
+database. This can lead to unauthorized access, data manipulation, or even complete data loss. To prevent SQL Injection
+attacks, always use prepared statements or parameterized queries, and never concatenate user inputs directly into SQL
+statements.
+
+### Example: SQL Injection Prevention in PHP
+
+```php
+$userInput = $_POST['username'];
+
+$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
+$stmt->bindParam(':username', $userInput);
+$stmt->execute();
+```
+
+### Example: SQL Injection Prevention in Magento 2
+
+```php
+$userInput = $this->getRequest()->getParam('username');
+
+$collection = $this->productCollectionFactory->create();
+$collection->addFieldToFilter('username', $userInput);
+```
+
+## Regular Security Updates and Patching
+
+Stay updated with the latest security patches and updates for your programming language, framework, and any external
+libraries you use. These updates often include security fixes for known vulnerabilities. Regularly applying these
+updates will help protect your application from potential security risks.
+
+## Secure Configuration and Sensitive Data Protection
+
+Ensure that sensitive configuration files, passwords, API keys, and other credentials are stored securely and not
+accessible to unauthorized individuals. Avoid hardcoding sensitive information directly into your code and utilize
+secure storage mechanisms such as environment variables or encrypted configuration files.
+
+## Implementing Secure Communication (HTTPS)
+
+Always use secure communication channels, such as HTTPS, to encrypt data transmission between clients and servers. This
+prevents eavesdropping, tampering, and protects sensitive information from being intercepted by attackers.
+
+## Regular Security Audits and Penetration Testing
+
+Perform regular security audits and penetration testing on your applications to identify and fix any vulnerabilities.
+Consider engaging third-party security professionals to conduct thorough security assessments and provide
+recommendations for further improvements.
+
+## Conclusion
+
+By following these best practices for secure development, you can significantly reduce the risk of security breaches and
+protect your applications and users' sensitive data. Remember to always stay updated with the latest security practices
+and be proactive in addressing potential vulnerabilities.
diff --git a/brief-explanation-of-each-component.md b/brief-explanation-of-each-component.md
index e69de29..905d738 100644
--- a/brief-explanation-of-each-component.md
+++ b/brief-explanation-of-each-component.md
@@ -0,0 +1,117 @@
+# Component Documentation
+
+[TOC]
+
+This documentation provides a brief explanation of each component in the PHP and Magento 2 ecosystem. Each component
+plays a crucial role in the development and functioning of a Magento 2 application. Familiarity with programming,
+specifically PHP and Magento 2, is assumed.
+
+## Magento Framework Component
+
+The Magento Framework Component is the foundation of the Magento 2 application. It provides a modular architecture and a
+set of libraries and interfaces that enable developers to create and extend Magento functionality. This component
+includes the `Magento\Framework` namespace and is responsible for essential features such as dependency injection, event
+management, configuration management, and more.
+
+Example of using the Magento Framework Component:
+
+```php
+use Magento\Framework\App\Bootstrap;
+require __DIR__ . '/app/bootstrap.php';
+
+$bootstrap = Bootstrap::create(BP, $_SERVER);
+$objectManager = $bootstrap->getObjectManager();
+```
+
+## Magento Module Component
+
+The Magento Module Component is responsible for encapsulating specific areas of functionality within a Magento 2
+application. Each module corresponds to a functionality or feature and contains the necessary code, configurations,
+layouts, and templates required to implement that feature. Modules are located in the `app/code` directory and follow
+the `VendorName_ModuleName` naming convention.
+
+Example module structure:
+
+```
+app
+├── code
+│ └── VendorName
+│ └── ModuleName
+│ ├── Block
+│ ├── Controller
+│ ├── etc
+│ ├── Model
+│ ├── Setup
+│ ├── view
+│ └── web
+└── ...
+```
+
+## Magento Theme Component
+
+The Magento Theme Component defines the visual appearance and layout of a Magento 2 storefront. It includes the
+necessary files such as CSS, JavaScript, images, templates, and layouts to define the presentation layer. Themes are
+located in the `app/design` directory and allow for customization and branding of the storefront.
+
+Example of a theme structure:
+
+```
+app
+├── design
+│ └── frontend
+│ └── VendorName
+│ └── theme
+│ ├── etc
+│ ├── Magento_Theme
+│ ├── media
+│ ├── web
+│ └── registration.php
+└── ...
+```
+
+## Magento Library Component
+
+The Magento Library Component provides a set of reusable libraries and functionality that can be used across multiple
+Magento 2 applications. These libraries are located in the `lib` directory and are shared dependencies among different
+modules and themes.
+
+Example of using a Magento library component:
+
+```php
+use Magento\Framework\Filesystem\DirectoryList;
+
+class MyCustomClass
+{
+ protected $directoryList;
+
+ public function __construct(DirectoryList $directoryList)
+ {
+ $this->directoryList = $directoryList;
+ }
+
+ public function getPath()
+ {
+ return $this->directoryList->getRoot();
+ }
+}
+```
+
+## Magento CLI Component
+
+The Magento CLI (Command Line Interface) Component provides a command-line tool that allows developers to perform
+various administrative and development tasks. It provides a convenient way to interact with the Magento 2 system, run
+scripts, manage modules, and perform database operations. The CLI commands are located in the `bin/magento` file.
+
+Example of running a CLI command:
+
+```shell
+php bin/magento cache:flush
+```
+
+## Conclusion
+
+Understanding the various components in the PHP and Magento 2 ecosystem is crucial for developing and maintaining
+Magento 2 applications. The Magento Framework Component, Magento Module Component, Magento Theme Component, Magento
+Library Component, and Magento CLI Component all contribute to the overall architecture and functionality of a Magento 2
+application. By utilizing these components effectively, developers can create powerful and customized e-commerce
+solutions.
diff --git a/cache-management.md b/cache-management.md
index e69de29..35368a0 100644
--- a/cache-management.md
+++ b/cache-management.md
@@ -0,0 +1,350 @@
+# Cache Management Documentation
+
+[TOC]
+
+## Introduction
+
+Cache management is a critical aspect of optimizing the performance and scalability of websites and web applications.
+Caching involves storing frequently accessed data in temporary storage, such as memory or disk, to reduce the time and
+resources required to fetch the data from the original source. Proper cache management can greatly improve the response
+time and overall user experience of a website.
+
+In this documentation, we will explore the cache management features in Magento 2, a popular PHP-based e-commerce
+platform. We will discuss the different types of cache, how to configure and manage them, and provide code snippets and
+examples to illustrate the concepts.
+
+## Types of Cache in Magento 2
+
+Magento 2 offers several types of cache, each serving a specific purpose. Understanding these cache types is crucial for
+efficient cache management. The main cache types in Magento 2 are:
+
+1. Configuration Cache: Stores the merged configuration data for the application. This cache speeds up the loading of
+ configuration settings by eliminating the need to parse and merge the configuration files on each request.
+
+2. Page Cache: Caches the entire HTML content of web pages, including blocks, layout, and other dynamic content. This
+ cache greatly improves the response time for frequently accessed pages.
+
+3. Block HTML Output Cache: Caches the output generated by individual blocks in Magento's layout system. This cache
+ minimizes the processing required to generate the HTML output of blocks, resulting in faster page rendering.
+
+4. Collection Data Cache: Caches the results of database queries performed to retrieve collections of database records.
+ This cache helps reduce the database load by storing the query results and serving them directly from the cache.
+
+5. EAV Entity Attribute Value Cache: Stores the attribute values of EAV entities, such as products and customers. This
+ cache avoids the need to retrieve attribute values from the database repeatedly, improving the performance of
+ attribute-related operations.
+
+## Cache Configuration and Management
+
+### Enable/Disable Cache
+
+Magento 2 provides a command-line tool, `bin/magento`, to enable or disable different cache types. To enable all cache
+types, use the following command:
+
+```
+bin/magento cache:enable
+```
+
+To enable specific cache types, use the `--type` option followed by the cache type code. For example, to enable only the
+page cache and block HTML output cache, use:
+
+```
+bin/magento cache:enable page_cache block_html
+```
+
+Similarly, to disable all cache types, use the following command:
+
+```
+bin/magento cache:disable
+```
+
+### Flush Cache
+
+Flushing the cache clears all stored cache data, forcing Magento to recompute and regenerate the cache on the next
+request. To flush all cache types, run the following command:
+
+```
+bin/magento cache:flush
+```
+
+To flush specific cache types, use the `--type` option followed by the cache type code. For example, to flush only the
+page cache and block HTML output cache, use:
+
+```
+bin/magento cache:flush page_cache block_html
+```
+
+### Cache Management from Admin Panel
+
+Magento 2 also provides a web-based cache management interface in the admin panel. To access it, navigate to **System
+** -> **Cache Management**. From there, you can enable/disable individual cache types and flush the entire cache or
+specific cache types.
+
+## Cache Invalidation
+
+Cache invalidation is the process of removing or updating cache data when the original data changes. In Magento 2, cache
+invalidation is handled automatically for many cases, such as when a product is updated or a block's content changes.
+However, there may be situations where you need to manually invalidate the cache.
+
+Magento 2 provides a cache tags mechanism to manage cache invalidation. Each cache entry is associated with one or more
+cache tags, and when a tag is invalidated, all associated cache entries are cleared. You can use
+the `Magento\Framework\App\Cache\Tag\Resolver` class to invalidate cache tags programmatically.
+
+Here is an example of cache tag invalidation in Magento 2:
+
+```php
+cacheTagResolver = $cacheTagResolver;
+ }
+
+ public function invalidateCacheTags(array $cacheTags)
+ {
+ foreach ($cacheTags as $cacheTag) {
+ $this->cacheTagResolver->invalidate($cacheTag);
+ }
+ }
+}
+```
+
+In this example, the `invalidateCacheTags` method takes an array of cache tags and invalidates them using
+the `invalidate` method of the `Resolver` class.
+
+## Types of Caching in Magento 2
+
+Magento 2 offers several caching types, each designed to cache specific types of data. Let's explore the most commonly
+used caching types in Magento 2.
+
+### Full Page Cache (FPC)
+
+Full Page Cache is a powerful caching mechanism in Magento 2 that stores fully rendered HTML pages. By caching the
+entire page, including all blocks and elements, Magento can serve the cached page directly from memory without executing
+expensive PHP code.
+
+Example: To enable FPC in Magento 2, navigate to **Stores > Configuration > Advanced > System > Full Page Cache** in the
+Admin Panel.
+
+### Object Cache
+
+Object Cache caches individual objects or entities, such as products, categories, and customer data. When an object is
+requested, Magento checks if it exists in the cache before fetching it from the database.
+
+Example: To cache an object in Magento 2, use the following code snippet:
+
+```php
+$cacheKey = 'my_object_cache_key';
+$cacheValue = $this->cache->load($cacheKey);
+
+if (!$cacheValue) {
+ // Object not found in cache, fetch it from the database
+ $object = $this->objectRepository->getById($objectId);
+
+ // Save the object in cache
+ $this->cache->save($object, $cacheKey, [], $cacheLifetime);
+} else {
+ // Object found in cache, use it
+ $object = unserialize($cacheValue);
+}
+```
+
+### Configuration Cache
+
+Configuration Cache stores the merged configuration data of your Magento 2 store. It includes the system configuration,
+module configurations, and other XML-based configurations. By caching the configuration, Magento avoids parsing and
+merging XML files on each request.
+
+Example: To enable Configuration Cache in Magento 2 via the command line, use the following command:
+
+```
+php bin/magento cache:enable config
+```
+
+### Layout Cache
+
+Layout Cache stores the layout XML for each page in your store. By caching the layout, Magento avoids parsing and
+merging XML files on each request, leading to improved performance.
+
+Example: To enable Layout Cache in Magento 2 via the command line, use the following command:
+
+```
+php bin/magento cache:enable layout
+```
+
+### Block Cache
+
+Block Cache caches individual blocks within a page. By caching blocks, Magento can serve the cached block content
+directly without executing the block's code.
+
+Example: To enable Block Cache for a specific block in Magento 2, add the following code to the block class:
+
+```php
+protected function _construct()
+{
+ $this->addData([
+ 'cache_lifetime' => 86400, // Cache lifetime in seconds
+ 'cache_key' => 'my_block_cache_key',
+ ]);
+}
+```
+
+### Collection Cache
+
+Collection Cache caches the result of database queries made by collection objects. By caching collections, Magento
+avoids executing the same database query multiple times, resulting in improved performance.
+
+Example: To cache a collection in Magento 2, use the following code snippet:
+
+```php
+$cacheKey = 'my_collection_cache_key';
+$cacheValue = $this->cache->load($cacheKey);
+
+if (!$cacheValue) {
+ // Collection not found in cache, fetch it from the database
+ $collection = $this->collectionFactory->create();
+
+ // Save the collection in cache
+ $this->cache->save(serialize($collection->getData()), $cacheKey, [], $cacheLifetime);
+} else {
+ // Collection found in cache, use it
+ $collection = unserialize($cacheValue);
+}
+```
+
+### Metadata Cache
+
+Metadata Cache stores metadata related to various entities, such as attributes, tables, and configurations. By caching
+metadata, Magento avoids querying the database for metadata information repeatedly.
+
+Example: To enable Metadata Cache in Magento 2 via the command line, use the following command:
+
+```
+php bin/magento cache:enable metadata
+```
+
+## Caching Configuration in Magento 2
+
+Magento 2 provides multiple ways to configure caching. Let's explore the two most common methods.
+
+### Configuration via the Admin Panel
+
+You can configure caching options via the Magento 2 Admin Panel. Navigate to **Stores > Configuration > Advanced >
+System > Cache Management**. Here, you can enable/disable specific cache types and configure cache settings.
+
+### Configuration via Command Line
+
+Alternatively, you can configure caching options via the command line using the `bin/magento cache` command. This method
+is useful, especially when automating deployment processes or managing multiple environments.
+
+Example: To enable the Full Page Cache via the command line, use the following command:
+
+```
+php bin/magento cache:enable full_page
+```
+
+## Caching Strategies
+
+To ensure efficient utilization of caching, it's essential to consider proper caching strategies. Let's explore some
+common caching strategies in Magento 2.
+
+### Automatic Cache Invalidation
+
+Magento 2 automatically invalidates caches when relevant data changes. For example, when a product is updated, the
+associated caches (object, block, collection, etc.) are invalidated, ensuring that the updated data is fetched from the
+original source.
+
+### Manual Cache Invalidation
+
+In some cases, you may need to manually invalidate specific caches, rather than relying on automatic invalidation.
+Magento 2 provides cache management commands that allow you to flush specific cache types or all caches.
+
+Example: To flush the Object Cache via the command line, use the following command:
+
+```
+php bin/magento cache:flush customer
+```
+
+### Cache Tags
+
+Cache Tags are a powerful feature in Magento 2 that allow you to assign tags to cached items. When a cache with a
+specific tag is invalidated, all associated cached items are also invalidated. This ensures that related data is
+refreshed when any item in the group is modified.
+
+Example: To add a cache tag to an object cache in Magento 2, use the following code snippet:
+
+```php
+$cacheKey = 'my_object_cache_key';
+$cacheValue = $this->cache->load($cacheKey, $cacheTag);
+
+if (!$cacheValue) {
+ // Object not found in cache, fetch it from the database
+ $object = $this->objectRepository->getById($objectId);
+
+ // Save the object in cache with the cache tag
+ $this->cache->save($object, $cacheKey, [$cacheTag], $cacheLifetime);
+} else {
+ // Object found in cache, use it
+ $object = unserialize($cacheValue);
+}
+```
+
+## Utilizing Cache in Code
+
+Magento 2 provides convenient methods and classes to utilize caching in your custom code. Let's explore how to use
+caching in code.
+
+### Cache Storage
+
+Magento 2 uses the `Magento\Framework\Cache\FrontendInterface` class to interact with the cache storage. You can inject
+this class in your code to read from or write to the cache.
+
+Example: To inject the cache storage in a class constructor:
+
+```php
+use Magento\Framework\Cache\FrontendInterface;
+
+class MyClass
+{
+ protected $cache;
+
+ public function __construct(
+ FrontendInterface $cache
+ ) {
+ $this->cache = $cache;
+ }
+}
+```
+
+### Reading from Cache
+
+To read data from the cache, use the `load($cacheKey)` method of the cache storage. If the data is not found in the
+cache, you can fetch it from the original source and save it in the cache.
+
+### Writing to Cache
+
+To write data to the cache, use the `save($cacheValue, $cacheKey, $cacheTags, $cacheLifetime)` method of the cache
+storage. Provide the cache value, cache key, associated cache tags (if any), and the cache lifetime in seconds.
+
+Example: To save data in the cache:
+
+```php
+$cacheKey = 'my_cache_key';
+$cacheValue = 'my_cache_value';
+$cacheTags = ['tag1', 'tag2'];
+$cacheLifetime = 86400; // 24 hours
+
+$this->cache->save($cacheValue, $cacheKey, $cacheTags, $cacheLifetime);
+```
+
+## Conclusion
+
+Understanding and effectively utilizing caching in Magento 2 can greatly improve the performance of your store. By
+configuring the appropriate cache types, managing cache strategies, and leveraging caching in your custom code, you can
+achieve faster response times and provide an optimal user experience for your customers.
diff --git a/cache-xml.md b/cache-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/cache.md b/cache_xml.md
similarity index 99%
rename from cache.md
rename to cache_xml.md
index a2a79c8..9503074 100644
--- a/cache.md
+++ b/cache_xml.md
@@ -1,4 +1,6 @@
-# Cache.xml Reference Documentation
+# `cache.xml` Reference Documentation
+
+[TOC]
## Introduction
@@ -73,7 +75,6 @@ attribute to either `true` or `false` to enable or disable the cache type, respe
### Example: Disabling the `block_html` Cache Type
```xml
-
```
diff --git a/caching-in-magento-2.md b/caching-in-magento-2.md
deleted file mode 100644
index e69de29..0000000
diff --git a/case-studies-of-problem-solving-in-magento-2.md b/case-studies-of-problem-solving-in-magento-2.md
index e69de29..f10dac5 100644
--- a/case-studies-of-problem-solving-in-magento-2.md
+++ b/case-studies-of-problem-solving-in-magento-2.md
@@ -0,0 +1,176 @@
+# Magento 2 Case Studies: Problem Solving Documentation
+
+[TOC]
+
+Welcome to the Magento 2 Case Studies documentation. In this document, we will explore real-life problem-solving
+scenarios in Magento 2, a widely-used PHP-based e-commerce platform. Each case study will present a specific problem and
+provide step-by-step instructions on how to approach and solve it. We will also include concrete examples and code
+snippets to illustrate the concepts discussed. Please note that this document assumes you have some familiarity with
+programming, specifically PHP and Magento 2, as it will use technical jargon and concepts that may be difficult for
+non-technical readers to understand. Let's dive in!
+
+## Case Study 1: Optimizing SQL Queries
+
+### Problem:
+
+You have noticed that your Magento 2 store is running slow, particularly when loading category pages. After analyzing
+the performance, you suspect that poorly optimized SQL queries are the root cause.
+
+### Solution:
+
+To optimize SQL queries in Magento 2, follow these steps:
+
+1. Enable SQL query logging in your Magento 2 installation. To do this, open your Magento 2 configuration
+ file (`app/etc/env.php`) and locate the `db` section. Set the `debug` parameter to `true` and save the file.
+
+ ```php
+ 'db' => [
+ 'table_prefix' => '',
+ 'connection' => [
+ 'default' => [
+ 'host' => 'localhost',
+ 'dbname' => 'magento',
+ 'username' => 'magento_user',
+ 'password' => 'magento_password',
+ 'active' => '1',
+ 'persistent' => null,
+ 'model' => 'mysql4',
+ 'engine' => 'innodb',
+ 'initStatements' => 'SET NAMES utf8;',
+ 'driver_options' => [
+ PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true,
+ ],
+ 'debug' => 'true', // Set this to true
+ ],
+ ],
+ ],
+ ```
+
+2. Perform the actions that trigger slow SQL queries in your Magento 2 store. This could include loading category pages
+ or performing searches.
+
+3. Check the generated SQL queries in the log files. Magento 2 logs SQL queries in the `var/debug/db.log` file.
+
+4. Identify the slow SQL queries by analyzing the logged queries. Look for queries that take longer to execute or have
+ inefficient joins or conditions.
+
+5. Analyze the slow queries and find opportunities for optimization. You can use EXPLAIN statements, database indexes,
+ or rewriting queries with better alternatives.
+
+6. Implement the optimizations identified in step 5. For example, you can add necessary indexes to the database tables
+ or refactor SQL queries to utilize more efficient joins or conditions.
+
+7. Test the performance after implementing the optimizations to ensure the desired improvements are achieved.
+
+Remember, optimizing SQL queries requires a deep understanding of the Magento 2 database structure and query execution.
+It is recommended to consult with experienced Magento 2 developers or database administrators if you are unsure about
+any optimizations.
+
+## Case Study 2: Customizing Checkout Process
+
+### Problem:
+
+You need to customize the checkout process in your Magento 2 store to meet specific business requirements. This includes
+adding custom fields, modifying the order summary, and integrating with a third-party payment gateway.
+
+### Solution:
+
+To customize the checkout process in Magento 2, follow these steps:
+
+1. Identify the specific customizations required for your checkout process. This could include adding custom fields,
+ modifying existing fields, or integrating with a third-party payment gateway.
+
+2. Create a custom module in Magento 2 to encapsulate your checkout customizations. This module will contain all the
+ necessary code and configuration files.
+
+3. Define the custom fields required for the checkout process in your module's configuration
+ file (`etc/checkout_fields.xml`). This file specifies the field names, types, and validation rules.
+
+ ```xml
+
+
+ Custom Field Label
+
+ ```
+
+4. Create a layout XML file (`view/frontend/layout/checkout_index_index.xml`) in your module to modify the checkout
+ layout.
+
+ ```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Vendor_Module/js/view/custom-field
+ 0
+
+ shippingAddress.custom_attributes
+ ui/form/field
+ Vendor_Module/form/element/custom-field
+
+
+ true
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ```
+
+5. Create a JavaScript component (`view/frontend/web/js/view/custom-field.js`) to handle the custom field behavior.
+
+ ```javascript
+ define([
+ 'uiComponent'
+ ], function (Component) {
+ 'use strict';
+
+ return Component.extend({
+ initialize: function () {
+ this._super();
+ // Add custom field behavior here
+ }
+ });
+ });
+ ```
+
+6. Implement the integration with the third-party payment gateway by extending the Magento 2 payment method model and
+ implementing the necessary API calls and callbacks.
+
+7. Test the checkout process thoroughly to ensure that the customizations are working as expected and integrating
+ correctly with the third-party payment gateway.
+
+Customizing the checkout process in Magento 2 requires a thorough understanding of the Magento 2 architecture, layout
+XML files, JavaScript components, and payment gateway integrations. It is recommended to consult Magento 2 developer
+documentation and seek guidance from experienced developers if you encounter any difficulties.
+
+## Conclusion
+
+In this documentation, we have explored two case studies of problem-solving in Magento 2. We discussed optimizing SQL
+queries and customizing the checkout process, providing step-by-step instructions and concrete examples to illustrate
+the concepts. Remember to approach problem-solving in Magento 2 with a deep understanding of the platform's architecture
+and best practices. For further assistance, consult the Magento 2 documentation and seek guidance from experienced
+Magento 2 developers. Happy problem-solving!
diff --git a/ci-cd.md b/ci-cd.md
deleted file mode 100644
index e69de29..0000000
diff --git a/cli-commands.md b/cli-commands.md
index e69de29..67cf362 100644
--- a/cli-commands.md
+++ b/cli-commands.md
@@ -0,0 +1,105 @@
+# CLI Commands Documentation
+
+[TOC]
+
+## Introduction
+
+This document provides a comprehensive guide to the Command Line Interface (CLI) commands available in Magento 2. CLI
+commands are powerful tools that allow developers and administrators to interact with Magento 2 from the command line.
+By executing these commands, you can perform various tasks such as installing or updating modules, flushing caches,
+compiling code, and more.
+
+## Prerequisites
+
+Before using the CLI commands, ensure that you have the following prerequisites:
+
+1. A working installation of Magento 2.
+2. A command line interface, such as the Terminal or Command Prompt.
+3. Familiarity with PHP and Magento 2 concepts.
+
+## Accessing CLI Commands
+
+To access the CLI commands, open a command line interface and navigate to the root directory of your Magento 2
+installation. Once you are in the correct directory, you can execute any available CLI command.
+
+## Syntax
+
+The basic syntax for executing a CLI command in Magento 2 is as follows:
+
+```bash
+php bin/magento [command_name] [options] [arguments]
+```
+
+- `php` refers to the PHP executable.
+- `bin/magento` is the entry point for all Magento CLI commands.
+- `[command_name]` is the name of the specific command you want to execute.
+- `[options]` are additional flags or parameters that modify the behavior of the command.
+- `[arguments]` are specific values or variables required by the command.
+
+Note that square brackets indicate optional elements.
+
+## Common CLI Commands
+
+This section provides an overview of some commonly used CLI commands in Magento 2.
+
+### `setup:upgrade`
+
+The `setup:upgrade` command is used to upgrade the Magento 2 instance after installing or updating modules. It applies
+database schema and data changes, ensuring that the system is up to date.
+
+Example usage:
+
+```bash
+php bin/magento setup:upgrade
+```
+
+### `cache:flush`
+
+The `cache:flush` command flushes all caches in the Magento 2 system. This is useful after making changes that need to
+be reflected immediately, such as modifying configuration files or updating module code.
+
+Example usage:
+
+```bash
+php bin/magento cache:flush
+```
+
+### `module:enable` and `module:disable`
+
+The `module:enable` and `module:disable` commands allow you to enable or disable specific modules in Magento 2. Enabling
+a module activates its functionality, while disabling it renders the module inactive.
+
+Example usage:
+
+```bash
+php bin/magento module:enable My_Module
+php bin/magento module:disable My_Module
+```
+
+### `setup:di:compile`
+
+The `setup:di:compile` command compiles the dependency injection configuration for Magento 2. This step is necessary
+after modifying the codebase or adding new modules to ensure that all dependencies are correctly resolved.
+
+Example usage:
+
+```bash
+php bin/magento setup:di:compile
+```
+
+### `cache:clean`
+
+The `cache:clean` command cleans the Magento 2 cache by removing all cached files. This is useful when troubleshooting
+caching issues or when you want to start with a clean cache.
+
+Example usage:
+
+```bash
+php bin/magento cache:clean
+```
+
+## Conclusion
+
+CLI commands in Magento 2 provide a powerful way to interact with the system from the command line. This documentation
+has covered some commonly used commands, but Magento 2 offers a wide range of commands for various tasks. By
+familiarizing yourself with these commands, you can enhance your development and administration workflow in Magento 2.
diff --git a/continious-integration-continious-deployment.md b/continious-integration-continious-deployment.md
new file mode 100644
index 0000000..8b8cb7d
--- /dev/null
+++ b/continious-integration-continious-deployment.md
@@ -0,0 +1,129 @@
+# Continuous Integration and Continuous Deployment Documentation
+
+[TOC]
+
+## Introduction
+
+In today's fast-paced software development landscape, companies are constantly looking for ways to improve their
+development processes. Continuous Integration (CI) and Continuous Deployment (CD) are two practices that have gained
+popularity in recent years. They allow developers to automate the process of building, testing, and deploying their
+software, resulting in faster and more reliable releases.
+
+This documentation will provide a comprehensive overview of Continuous Integration and Continuous Deployment concepts,
+as well as practical examples of implementing these practices in a Magento 2 project.
+
+## Continuous Integration
+
+### What is Continuous Integration?
+
+Continuous Integration is the practice of frequently integrating code changes from multiple developers into a shared
+repository. The goal is to detect and resolve integration issues as early as possible. This is achieved by automatically
+building and testing the software whenever changes are made.
+
+The key principles of Continuous Integration include:
+
+- **Maintaining a Single Source Repository**: All developers work on a common codebase, ensuring that everyone is always
+ working on the latest version of the software.
+- **Automated Build and Test Processes**: Code changes trigger automated build and test processes, allowing developers
+ to quickly identify and fix issues.
+- **Fast Feedback Loop**: Developers receive immediate feedback on the quality of their code, enabling them to address
+ any issues promptly.
+
+### Benefits of Continuous Integration
+
+Continuous Integration offers several benefits, including:
+
+- **Early Detection of Issues**: By integrating and testing code frequently, issues are identified and resolved earlier
+ in the development process, reducing the cost and effort required for bug fixing.
+- **Improved Collaboration**: Since all developers are working on a shared codebase, it fosters collaboration and
+ encourages knowledge sharing among team members.
+- **Increased Confidence in Releases**: Continuous Integration ensures that software is always in a releasable state,
+ reducing the risk of introducing new bugs or breaking existing functionality.
+
+### Continuous Integration Workflow
+
+The typical Continuous Integration workflow involves the following steps:
+
+1. Developers make changes to the codebase and commit them to the shared repository.
+2. A Continuous Integration server (such as Jenkins or Travis CI) monitors the repository for changes.
+3. Upon detecting a change, the server automatically triggers the build process.
+4. The build process compiles the code, runs automated tests, and generates artifacts (such as executable files or
+ deployment packages).
+5. The server reports the build results and notifies the team of any issues.
+6. Developers address any identified issues and repeat the process until the build is successful.
+
+### Implementing Continuous Integration with Magento 2
+
+To implement Continuous Integration with Magento 2, you can utilize popular CI platforms like Jenkins or GitLab CI/CD.
+Here's an example utilizing Jenkins:
+
+1. Set up a Jenkins server and configure it to monitor your Magento 2 repository for changes.
+2. Create a Jenkins job that defines your build process. This job should include steps to:
+
+ - Install dependencies and configure the build environment.
+ - Compile the code and generate necessary artifacts.
+ - Run automated tests to ensure code quality.
+ - Report build results and notify the team of any issues.
+
+3. Configure your Jenkins job to trigger on each commit to the repository.
+4. Monitor the Jenkins console or receive notifications to promptly address any build issues.
+
+By implementing Continuous Integration for your Magento 2 project, you can ensure that code changes are reliably built,
+tested, and integrated into your software.
+
+## Continuous Deployment
+
+### What is Continuous Deployment?
+
+Continuous Deployment is an extension of Continuous Integration that automates the process of releasing software to
+production environments. It aims to minimize manual intervention and reduce the time between code changes and their
+availability to end-users.
+
+With Continuous Deployment, every successful build from the Continuous Integration process is automatically deployed to
+production, assuming it passes a set of predefined criteria (e.g., successful tests, code reviews, etc.).
+
+### Benefits of Continuous Deployment
+
+Continuous Deployment offers several benefits, including:
+
+- **Faster Time-to-Market**: By automating the deployment process, software updates can be released to production
+ rapidly, providing new features and bug fixes to end-users without delays.
+- **Reduced Risk**: Automated deployment processes reduce the risk of human error, ensuring that deployments are
+ consistent and reliable across environments.
+- **Improved Feedback Loop**: With Continuous Deployment, developers receive faster feedback from end-users, enabling
+ them to iterate and improve the software more rapidly.
+
+### Continuous Deployment Workflow
+
+The typical Continuous Deployment workflow involves the following steps:
+
+1. Developers commit code changes to the shared repository.
+2. Continuous Integration process builds, tests, and verifies the code changes.
+3. Upon successfully passing the Continuous Integration process, the build artifacts are automatically deployed to a
+ staging environment.
+4. Automated tests are executed in the staging environment to ensure the changes work as expected.
+5. If all tests pass, the deployment process proceeds to production, automatically deploying the changes to end-users.
+
+### Implementing Continuous Deployment with Magento 2
+
+To implement Continuous Deployment with Magento 2, you can use deployment tools like Deployer, Capistrano, or GitLab
+CI/CD. Here's an example utilizing GitLab CI/CD:
+
+1. Configure your GitLab CI/CD pipeline to trigger on each successful build from the Continuous Integration process.
+2. Define a deployment stage in your GitLab CI/CD configuration that deploys the build artifacts to a staging
+ environment.
+3. Execute automated tests in the staging environment to ensure the changes function correctly.
+4. If the tests pass, define another deployment stage to automatically deploy the changes to production.
+
+By implementing Continuous Deployment for your Magento 2 project, you can automate the release process, reducing manual
+effort and accelerating the delivery of new features and bug fixes to your end-users.
+
+## Conclusion
+
+Continuous Integration and Continuous Deployment are valuable practices that enable developers to build, test, and
+release software more efficiently and reliably. By adopting these practices in your Magento 2 project, you can enhance
+collaboration, increase confidence in releases, and deliver software updates to end-users faster.
+
+Remember to choose appropriate Continuous Integration and Continuous Deployment tools that fit the specific needs of
+your project and team. With proper implementation and utilization, you can significantly improve your software
+development process and achieve a more seamless and reliable release cycle.
\ No newline at end of file
diff --git a/core-features.md b/core-features.md
index 8b3d724..725474c 100644
--- a/core-features.md
+++ b/core-features.md
@@ -1,21 +1,6 @@
# Core Features of Magento 2
-- [Core Features of Magento 2](#core-features-of-magento-2)
- * [Catalog Management](#catalog-management)
- * [Checkout, Payment, and Shipping](#checkout-payment-and-shipping)
- * [SEO and Marketing](#seo-and-marketing)
- * [Mobile Commerce](#mobile-commerce)
- * [Analytics and Reporting](#analytics-and-reporting)
- * [International Support](#international-support)
- * [Customer Accounts](#customer-accounts)
- * [Order Management](#order-management)
- * [Security](#security)
- * [Developer Tools](#developer-tools)
- * [Multistore Functionality](#multistore-functionality)
- * [Content Staging and Preview](#content-staging-and-preview)
- * [ElasticSearch](#elasticsearch)
- * [Page Builder](#page-builder)
- * [Customer Loyalty Tools](#customer-loyalty-tools)
+[TOC]
Magento 2 is equipped with an extensive set of powerful features, designed to provide businesses with unparalleled
flexibility, scalability, and control over their eCommerce platform. Here, we delve into a few key features.
diff --git a/cron-groups-xml.md b/cron-groups-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/cron-jobs-xml.md b/cron-jobs-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/cron-jobs.md b/cron-jobs.md
index 2335dc0..8acca75 100644
--- a/cron-jobs.md
+++ b/cron-jobs.md
@@ -1,33 +1,17 @@
# Cron Jobs in Magento 2
-- [Introduction](#introduction)
-- [Setting up a Cron Job](#setting-up-a-cron-job)
- - [Step 1: Declare the Cron Job in `crontab.xml`](#step-1)
- - [Step 2: Define the Cron Job Method](#step-2)
-- [Executing a Cron Job](#executing-a-cron-job)
-- [Viewing and Managing Cron Tasks](#viewing-and-managing-cron-tasks)
-- [Cron Groups](#cron-groups)
- - [Defining a Cron Group](#defining-a-cron-group)
- - [Running a Specific Cron Group](#running-a-specific-cron-group)
- - [Benefits of Using Cron Groups](#benefits-of-using-cron-groups)
-- [Best Practices for Cron Jobs](#best-practices-for-cron-jobs)
-
-
-## Introduction
+[TOC]
+## Introduction
Cron jobs are scheduled tasks that run automatically at specified intervals. Magento uses cron jobs to run tasks such as
reindexing, generating reports, sending newsletters, and many more. Cron jobs are essential to keep your Magento 2 store
functioning correctly.
-
## Setting up a Cron Job
-
Setting up a cron job in Magento involves two main steps: declaring the cron job in the `crontab.xml` file, and defining
the method that will be executed when the cron job runs.
-
### Step 1: Declare the Cron Job in `crontab.xml`
-
First, we need to declare our cron job in a `crontab.xml` file. This file should be located in the `etc` directory of
your module. If it doesn't exist, create one.
@@ -52,9 +36,7 @@ In the above code:
- `method`: This is the method in your class that will be called.
- `schedule`: This determines how often your cron job will run, based on cron syntax.
-
### Step 2: Define the Cron Job Method
-
Now, we need to create the cron class in the `Vendor\Module\Cron` directory and define the `execute()` method. This is
the method that will be executed when the cron job runs.
@@ -86,9 +68,7 @@ In this class:
The `LoggerInterface` is used to log messages. The `execute()` method logs a message when the cron job runs
successfully.
-
## Executing a Cron Job
-
To execute all Magento cron jobs, you run the following command in the terminal:
```bash
@@ -97,9 +77,7 @@ php bin/magento cron:run
This command will execute all cron jobs that are scheduled to run at the time the command is executed.
-
## Viewing and Managing Cron Tasks
-
To view a list of all scheduled cron jobs and their status, you can use the following command:
```bash
@@ -117,15 +95,11 @@ php bin/magento cron:remove
Replace `` with the code of the job you wish to remove.
-
## Cron Groups
-
Magento 2 uses cron groups to manage related tasks together. A cron group is a set of cron jobs that are managed as a
unit. All cron jobs in a group will run in the same process to ensure the resources are effectively used.
-
### Defining a Cron Group
-
Cron groups are defined in the `crontab.xml` file in the same way as individual cron jobs. The `group id` attribute is
used to define the group. Jobs within the same group are enclosed within the same `group` tags.
@@ -148,9 +122,7 @@ Here is an example of how to define a cron group:
In this example, both `my_cronjob1` and `my_cronjob2` are part of `the my_cron_group group`.
-
### Running a Specific Cron Group
-
To run all jobs in a specific cron group, use the following command:
```bash
@@ -159,9 +131,7 @@ php bin/magento cron:run --group="my_cron_group"
This command will run all cron jobs in `the my_cron_group group`.
-
### Benefits of Using Cron Groups
-
Using cron groups provides a few benefits:
You can manage related cron jobs together, making your cron configuration easier to understand and maintain.
@@ -170,12 +140,10 @@ If an error occurs in one job, it won't affect the other jobs in the group.
Remember, the effective management of cron jobs, including the use of cron groups, is vital for maintaining the
performance and functionality of your Magento 2 store.
-
## Best Practices for Cron Jobs
-
- Always log the start, end, and any exceptions in your cron jobs. This will help in debugging issues later.
- Always return $this at the end of your cron job method to ensure that the method chain isn't broken.
- Don't overload your server with too many simultaneous cron jobs. Schedule your jobs efficiently to avoid high server
load.
- Keep the execution time of your cron jobs as short as possible. Long-running jobs can slow down the overall
- performance of your Magento store.
+ performance of your Magento store.
\ No newline at end of file
diff --git a/cron_groups_xml.md b/cron_groups_xml.md
new file mode 100644
index 0000000..ffbd478
--- /dev/null
+++ b/cron_groups_xml.md
@@ -0,0 +1,155 @@
+# `cron_groups.xml` Reference Documentation
+
+[TOC]
+
+## Overview
+
+The `cron_groups.xml` file is a configuration file used in Magento 2 to define cron groups and their associated cron
+jobs. Cron jobs are scheduled tasks that are executed automatically at specified intervals. Cron groups allow you to
+categorize and manage cron jobs more effectively.
+
+This reference documentation will provide you with a detailed explanation of the `cron_groups.xml` file and its
+structure. It will also cover the various elements and attributes used in this file, along with their purpose and usage.
+
+## File Location
+
+The `cron_groups.xml` file is located in the `/etc` directory of your Magento 2 module. It follows the `XML`
+file format and can be edited using any text editor or integrated development environment (IDE) of your choice.
+
+## File Structure
+
+The `cron_groups.xml` file follows a specific structure that consists of several XML elements and attributes. Here is an
+example of the basic structure:
+
+```xml
+
+
+
+ 1
+ 4
+ 2
+ 10
+ 60
+ 600
+ 0
+
+
+
+```
+
+The root element of the file is ``, which contains several child elements representing cron groups. Each cron
+group is defined within a `` element, with a unique `id` attribute identifying it. The various configurations for
+each cron group are specified as child elements within the `` element.
+
+## Elements and Attributes
+
+### ``
+
+The `` element represents a cron group and contains various child elements for configuring the group. It has the
+following attribute:
+
+- `id` (required): Specifies a unique identifier for the cron group. This identifier is referenced in other
+ configuration files to assign cron jobs to this group.
+
+Example:
+
+```xml
+
+
+
+
+```
+
+### ``
+
+The `` element determines how often the cron schedule is regenerated. It sets the frequency in
+minutes for generating the cron schedule.
+
+Example:
+
+```xml
+
+1
+```
+
+### ``
+
+The `` element specifies the number of minutes ahead of the current time for which the cron schedule
+is generated. It helps in ensuring that scheduled tasks are executed on time by allowing a buffer for processing.
+
+Example:
+
+```xml
+
+4
+```
+
+### ``
+
+The `` element defines the maximum number of minutes for which a cron job can be scheduled. After
+this time, the schedule entry for the cron job will be removed from the schedule tables.
+
+Example:
+
+```xml
+
+2
+```
+
+### ``
+
+The `` element determines how often the cron history is cleaned up. It sets the frequency in
+minutes for cleaning up the history of executed cron jobs.
+
+Example:
+
+```xml
+
+10
+```
+
+### ``
+
+The `` element specifies the number of minutes after which successful cron job entries are
+removed from the history tables.
+
+Example:
+
+```xml
+
+60
+```
+
+### ``
+
+The `` element defines the number of minutes after which failed cron job entries are removed
+from the history tables.
+
+Example:
+
+```xml
+
+600
+```
+
+### ``
+
+The `` element determines whether cron jobs assigned to the cron group should be executed in a
+separate process. It accepts a boolean value: `0` for false and `1` for true.
+
+Example:
+
+```xml
+
+0
+```
+
+## Conclusion
+
+The `cron_groups.xml` file is a crucial configuration file used in Magento 2 for defining cron groups and their
+associated cron jobs. By understanding its structure and the various elements and attributes it provides, you can
+effectively manage and schedule cron jobs within your Magento 2 module.
+
+Remember to make any necessary modifications to this file with caution, as incorrect configurations may lead to
+unexpected behaviors or issues with your cron jobs.
diff --git a/cron_jobs.md b/cron_jobs_xml.md
similarity index 98%
rename from cron_jobs.md
rename to cron_jobs_xml.md
index 243d1a2..9a830a5 100644
--- a/cron_jobs.md
+++ b/cron_jobs_xml.md
@@ -1,4 +1,6 @@
-# Cron Jobs XML Reference Documentation
+# `cron_jobs.xml` Reference Documentation
+
+[TOC]
## Introduction
diff --git a/css-preprocessing.md b/css-preprocessing.md
index e69de29..1bc73b9 100644
--- a/css-preprocessing.md
+++ b/css-preprocessing.md
@@ -0,0 +1,219 @@
+# CSS Preprocessing Documentation
+
+[TOC]
+
+## Introduction
+
+CSS preprocessing is a technique used to enhance the functionality and flexibility of CSS (Cascading Style Sheets). It
+involves using a preprocessor to write CSS in a more dynamic and efficient manner. This documentation will provide an
+overview of CSS preprocessing, explain its benefits, and discuss some popular CSS preprocessors such as Sass and Less.
+Additionally, we will explore how CSS preprocessing can be utilized in PHP and Magento 2 environments.
+
+## What is CSS Preprocessing?
+
+CSS preprocessing is the process of writing CSS using a preprocessor, which is a tool that extends the capabilities of
+CSS by adding features like variables, mixins, nesting, and more. These features allow developers to write CSS in a more
+modular and reusable way, resulting in cleaner and more maintainable code.
+
+Preprocessors work by taking input files written in a preprocessor language and transforming them into valid CSS files
+that can be interpreted by browsers. This transformation is typically done using a command-line tool or a build system.
+
+## Benefits of CSS Preprocessing
+
+CSS preprocessing offers several key benefits for web developers:
+
+### 1. Variables
+
+CSS preprocessors allow the use of variables, which can be defined once and reused throughout the codebase. This makes
+it easier to maintain consistency in styling, as changes to a variable value will be automatically reflected across all
+instances.
+
+Example:
+
+```scss
+$primary-color: #007bff;
+.button {
+ background-color: $primary-color;
+}
+```
+
+### 2. Mixins
+
+Mixins are reusable blocks of CSS code that can be included in multiple selectors. They allow developers to define
+complex styles once and apply them wherever needed. This reduces code duplication and improves code organization.
+
+Example:
+
+```scss
+@mixin button-styles {
+ padding: 10px;
+ background-color: $primary-color;
+ color: white;
+ border-radius: 5px;
+}
+
+.button {
+ @include button-styles;
+}
+
+.submit-button {
+ @include button-styles;
+ background-color: green;
+}
+```
+
+### 3. Nesting
+
+CSS preprocessors support nesting, allowing developers to nest selectors inside other selectors. This makes the code
+structure more intuitive and easier to read.
+
+Example:
+
+```scss
+.container {
+ background-color: #f1f1f1;
+
+ .button {
+ padding: 10px;
+ background-color: $primary-color;
+ color: white;
+ }
+}
+```
+
+### 4. Extending
+
+Preprocessors support extending, which enables the inheritance of styles from one selector to another. This promotes
+code reuse and reduces redundancy.
+
+Example:
+
+```scss
+.button {
+ padding: 10px;
+ background-color: $primary-color;
+ color: white;
+}
+
+.submit-button {
+ @extend .button;
+ background-color: green;
+}
+```
+
+### 5. Modularity
+
+CSS preprocessors allow developers to split their code into multiple files, making it easier to manage and organize
+styles. These files can then be imported into a single master file, which will be compiled into a single CSS file by the
+preprocessor.
+
+Example:
+
+```scss
+// base.scss
+$primary-color: #007bff;
+
+.button {
+ padding: 10px;
+ background-color: $primary-color;
+ color: white;
+}
+
+// main.scss
+@import 'base';
+
+.container {
+ ...
+}
+```
+
+## Popular CSS Preprocessors
+
+There are several popular CSS preprocessors available, but two of the most widely used are Sass (Syntactically Awesome
+Style Sheets) and Less. Both preprocessors offer similar features and are supported by a large community.
+
+### Sass
+
+Sass is a powerful and mature CSS preprocessor that provides a wide range of features. It has a large and active
+community, making it easy to find resources and support. Sass supports two syntaxes: SCSS (Sassy CSS), which is a
+superset of CSS, and the indented syntax.
+
+To compile Sass files into CSS, you can use the command line or build tools like Grunt, Gulp, or Webpack.
+
+Example of SCSS syntax:
+
+```scss
+$primary-color: #007bff;
+
+.button {
+ padding: 10px;
+ background-color: $primary-color;
+ color: white;
+}
+```
+
+Example of indented syntax:
+
+```sass
+$primary-color: #007bff
+
+.button
+ padding: 10px
+ background-color: $primary-color
+ color: white
+```
+
+### Less
+
+Less is another popular CSS preprocessor that provides similar features to Sass. It has a more concise syntax compared
+to Sass, resembling traditional CSS. Less also has a large community and can be compiled using command-line tools or
+build systems.
+
+Example:
+
+```less
+@primary-color: #007bff;
+
+.button {
+ padding: 10px;
+ background-color: @primary-color;
+ color: white;
+}
+```
+
+## Using CSS Preprocessing in PHP and Magento 2
+
+CSS preprocessing can be integrated into PHP and Magento 2 projects to enhance the styling capabilities. To utilize CSS
+preprocessors in these environments, additional setup steps are required.
+
+1. **PHP**: To use CSS preprocessing in PHP projects, you need to set up a build system or task runner like Grunt, Gulp,
+ or Webpack. These tools can be configured to watch and compile your preprocessor files into CSS whenever changes are
+ made. The compiled CSS files can then be included in your PHP files as usual.
+
+2. **Magento 2**: Magento 2 utilizes the LESS preprocessor by default for its frontend styles. To customize and extend
+ styles in Magento 2, you can create a custom theme and override the default LESS files. This allows you to leverage
+ the power of LESS and its preprocessing features within the Magento 2 framework.
+
+Example of overriding a LESS file in a Magento 2 custom theme:
+
+```
+app/design/frontend/MyVendor/my-theme/web/css/source/_extend.less
+```
+
+```less
+@primary-color: #007bff;
+
+.button {
+ padding: 10px;
+ background-color: @primary-color;
+ color: white;
+}
+```
+
+## Conclusion
+
+CSS preprocessing is a powerful technique that enhances the capabilities of CSS by introducing features like variables,
+mixins, nesting, and more. By using CSS preprocessors like Sass or Less, developers can write cleaner and more
+maintainable code. In PHP and Magento 2 environments, CSS preprocessing can be integrated with build systems or custom
+themes to unlock the full potential of CSS preprocessing. Experiment with CSS preprocessors and experience the benefits
+of improved organization, modularity, and code reusability in your projects.
diff --git a/data-interfaces-and-models.md b/data-interfaces-and-models.md
index e69de29..d3bbff6 100644
--- a/data-interfaces-and-models.md
+++ b/data-interfaces-and-models.md
@@ -0,0 +1,130 @@
+# Data Interfaces and Models Documentation
+
+[TOC]
+
+## Introduction
+
+Data interfaces and models are essential components in Magento 2 development. They provide a structured way to represent
+and manipulate data, ensuring consistency and maintainability in your codebase. This documentation will explore the
+concepts of data interfaces and models in Magento 2, their purpose, and how to use them effectively.
+
+## Data Interfaces
+
+Data interfaces define the structure and behavior of data objects in Magento 2. They act as contracts that enforce a set
+of methods that must be implemented by any class that wants to use or manipulate the data.
+
+Data interfaces are typically defined in the `Api/Data` directory of a module and follow a naming convention
+of `EntityInterface`. For example, if you have a module called `Vendor_Module`, the data interface for a custom entity
+could be defined in `Vendor/Module/Api/Data/CustomEntityInterface.php`.
+
+Let's take a look at an example data interface for a `CustomEntity`:
+
+```php
+_init(\Vendor\Module\Model\ResourceModel\CustomEntity::class);
+ }
+
+ /**
+ * Get the entity ID.
+ *
+ * @return int|null
+ */
+ public function getId()
+ {
+ return $this->getData(self::ID);
+ }
+
+ /**
+ * Set the entity ID.
+ *
+ * @param int $id
+ * @return $this
+ */
+ public function setId($id)
+ {
+ return $this->setData(self::ID, $id);
+ }
+
+ // Other methods...
+}
+```
+
+In this example, the `CustomEntity` model extends the `AbstractModel` class provided by Magento 2. This abstract class
+provides common functionality for models, such as data storage and retrieval.
+
+The model implements the `CustomEntityInterface`, which enforces the implementation of the methods defined in the
+interface. The implementation of the methods simply delegates the calls to the `getData()` and `setData()` methods
+provided by the `AbstractModel` class.
+
+Models should also define a constructor that initializes the resource model. The resource model is responsible for
+interacting with the database or other data storage mechanisms. In this example, the resource model for `CustomEntity`
+is defined in `Vendor/Module/Model/ResourceModel/CustomEntity.php`.
+
+By utilizing models, you can encapsulate the logic for retrieving and manipulating data in a structured and consistent
+manner.
+
+## Conclusion
+
+Data interfaces and models play a crucial role in Magento 2 development, providing a structured way to represent and
+manipulate data. By defining data interfaces, you can enforce a consistent contract for interacting with data objects.
+Models, on the other hand, are responsible for implementing these interfaces, encapsulating the logic for data retrieval
+and manipulation.
+
+By following the conventions and best practices outlined in this documentation, you can ensure the maintainability and
+consistency of your Magento 2 codebase.
diff --git a/database-access-and-orm.md b/database-access-and-orm.md
index e69de29..af8f425 100644
--- a/database-access-and-orm.md
+++ b/database-access-and-orm.md
@@ -0,0 +1,188 @@
+# Database Access and ORM Documentation
+
+[TOC]
+
+## Introduction
+
+Database access and Object-Relational Mapping (ORM) are fundamental concepts in software development. In this
+documentation, we will explore the various aspects of database access and ORM, specifically in the context of PHP and
+Magento 2. We will discuss the importance of these concepts, their benefits, and provide concrete examples and code
+snippets to demonstrate their usage.
+
+## Database Access
+
+### Connecting to a Database
+
+To interact with a database in PHP, you need to establish a connection. In Magento 2, this can be achieved using
+the `Magento\Framework\App\ResourceConnection` class. Here's an example:
+
+```php
+get(ResourceConnection::class)->getConnection();
+```
+
+### Executing Queries
+
+Once you have a connection, you can execute SQL queries. The `Magento\Framework\DB\Adapter\AdapterInterface` interface
+provides methods like `query`, `fetchRow`, `fetchAll`, etc., to execute queries and retrieve results. Here's an example:
+
+```php
+select()
+ ->from('catalog_product_entity')
+ ->where('price > ?', 100);
+
+$result = $connection->fetchAll($select);
+```
+
+### Retrieving Data
+
+Fetching data from a database table involves executing a query and processing the results. You can use the `fetchRow`
+method to retrieve a single row, or `fetchAll` to get multiple rows as an array. Here's an example:
+
+```php
+select()
+ ->from('catalog_product_entity')
+ ->where('entity_id = ?', $productId);
+
+$product = $connection->fetchRow($select);
+
+echo $product['name'];
+```
+
+### Inserting Data
+
+To insert data into a database table, you can use the `insert` method provided by the `AdapterInterface`. Here's an
+example:
+
+```php
+ 'New Product',
+ 'price' => 99.99,
+];
+
+$connection->insert('catalog_product_entity', $data);
+```
+
+### Updating Data
+
+Updating existing data in a database table is done using the `update` method. You specify the table name, the data to
+update, and any conditions. Here's an example:
+
+```php
+ 109.99,
+];
+
+$where = ['entity_id = ?' => 42];
+
+$connection->update('catalog_product_entity', $data, $where);
+```
+
+### Deleting Data
+
+To delete data from a database table, you can use the `delete` method. It requires the table name and any conditions to
+specify which rows to delete. Here's an example:
+
+```php
+ 42];
+
+$connection->delete('catalog_product_entity', $where);
+```
+
+## ORM (Object-Relational Mapping)
+
+### Mapping Database Tables to PHP Classes
+
+ORM allows you to map database tables to PHP classes, making it easier to work with data in an object-oriented manner.
+In Magento 2, this is achieved using the Entity-Attribute-Value (EAV) system. Each database table corresponds to an
+entity, and each column represents an attribute. Here's an example:
+
+```php
+_init('Vendor\Module\Model\ResourceModel\Product');
+ }
+}
+```
+
+### CRUD Operations with ORM
+
+ORM simplifies CRUD (Create, Read, Update, Delete) operations by providing methods to perform these operations on
+entities. For example, to create a new entity, you can use the `create` method. Here's an example:
+
+```php
+get(ProductFactory::class)->create();
+$product->setName('New Product');
+$product->setPrice(99.99);
+$product->save();
+```
+
+### Fetching Related Data
+
+ORM allows you to easily fetch related data using relationships defined in the entity classes. For example, if
+a `Product` entity has a many-to-one relationship with a `Category` entity, you can fetch the category of a product
+using the `getCategory` method. Here's an example:
+
+```php
+get(ProductFactory::class)->create()->load($productId);
+$category = $product->getCategory();
+```
+
+### Updating and Saving Entities
+
+Updating an entity is as simple as loading it and modifying its attributes. Once you've made the changes, you can save
+the entity back to the database using the `save` method. Here's an example:
+
+```php
+get(ProductFactory::class)->create()->load($productId);
+$product->setName('Updated Product');
+$product->save();
+```
+
+### Deleting Entities
+
+To delete an entity, you can use the `delete` method. Here's an example:
+
+```php
+get(ProductFactory::class)->create()->load($productId);
+$product->delete();
+```
+
+## Conclusion
+
+In this documentation, we covered the concepts of database access and ORM in PHP and Magento 2. We discussed connecting
+to a database, executing queries, retrieving and manipulating data, and using ORM for simplified CRUD operations. By
+leveraging these concepts effectively, you can build robust and efficient applications that interact seamlessly with
+databases.
diff --git a/db-schema-xml.md b/db-schema-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/db_schema_xml.md b/db_schema_xml.md
new file mode 100644
index 0000000..1680613
--- /dev/null
+++ b/db_schema_xml.md
@@ -0,0 +1,126 @@
+# `db_schema.xml` Reference Documentation
+
+[TOC]
+
+## Introduction
+
+The `db_schema.xml` file is an essential part of the Magento 2 module development process. It provides a way to define
+the database schema for your module, including tables, columns, indexes, and other related entities. This reference
+documentation aims to explain the various elements and attributes used in the `db_schema.xml` file and provide concrete
+examples and code snippets for better understanding.
+
+## File Structure
+
+The `db_schema.xml` file should be located in the `etc` directory of your module. It follows a specific XML structure,
+as follows:
+
+```xml
+
+
+
+
+```
+
+In the above code snippet, you can see the XML declaration at the beginning and the root `schema` element, which serves
+as the container for defining your module's database schema.
+
+## Tables
+
+To define a table in your module's schema, you should use the `table` element within the `schema` element. The `table`
+element can have the following attributes:
+
+- `name`: The name of the table.
+- `resource`: The resource name used to retrieve a database connection.
+- `engine`: The storage engine used for the table (optional, defaults to `innodb`).
+
+Here's an example of defining a table in the `db_schema.xml` file:
+
+```xml
+
+
+
+
+
+
+```
+
+## Columns
+
+Within a table, you can define columns using the `column` element. The `column` element can have the following
+attributes:
+
+- `name`: The name of the column.
+- `dataType`: The data type of the column.
+- `length`: The length of the column (optional, depends on the data type).
+- `nullable`: Whether the column allows NULL values (`true` or `false`, optional, defaults to `false`).
+- `comment`: A descriptive comment for the column (optional).
+
+Here's an example of defining columns within a table:
+
+```xml
+
+
+
+
+
+
+```
+
+## Indexes
+
+You can define indexes for a table using the `index` element within the `table` element. The `index` element can have
+the following attributes:
+
+- `name`: The name of the index.
+- `indexType`: The type of the index (`btree`, `fulltext`, or `hash`, optional, defaults to `btree`).
+- `referenceId`: The name of the column being referenced by the index.
+- `referenceTable`: The name of the table being referenced by the index.
+
+Here's an example of defining an index within a table:
+
+```xml
+
+
+
+
+
+
+
+
+
+```
+
+## Foreign Keys
+
+To define a foreign key constraint between two tables, you can use the `constraint` element within the `table` element.
+The `constraint` element can have the following attributes:
+
+- `name`: The name of the foreign key constraint.
+- `referenceId`: The name of the column being referenced by the foreign key.
+- `referenceTable`: The name of the table being referenced by the foreign key.
+- `onDelete`: The action to perform when the referenced row is deleted (`cascade`, `set null`, `set default`,
+ or `restrict`, optional, defaults to `restrict`).
+- `onUpdate`: The action to perform when the referenced row is updated (`cascade`, `set null`, `set default`,
+ or `restrict`, optional, defaults to `restrict`).
+
+Here's an example of defining a foreign key constraint within a table:
+
+```xml
+
+
+
+
+
+
+
+```
+
+## Conclusion
+
+The `db_schema.xml` file provides a way to define the database schema for your Magento 2 module. By understanding its
+elements and attributes, you can effectively define tables, columns, indexes, and foreign keys. This reference
+documentation aimed to provide a comprehensive overview of the `db_schema.xml` file and its usage in Magento 2 module
+development.
diff --git a/developing-extensions-in-magento-2.md b/developing-extensions-in-magento-2.md
index e69de29..6b94daa 100644
--- a/developing-extensions-in-magento-2.md
+++ b/developing-extensions-in-magento-2.md
@@ -0,0 +1,240 @@
+# Magento 2 Extension Development Documentation
+
+[TOC]
+
+Welcome to the documentation for developing extensions in Magento 2. This guide will provide you with all the necessary
+information to get started with building extensions for the Magento 2 platform. Whether you are a seasoned Magento
+developer or just starting out, this documentation will help you understand the process and best practices for creating
+powerful extensions.
+
+## 1. Introduction
+
+Magento 2 provides a robust and flexible architecture for building extensions that enhance the functionality of the
+platform. Extensions can modify existing features or introduce new ones, allowing merchants to customize their Magento
+stores to meet their specific business requirements.
+
+This documentation will cover various aspects of extension development, including extension structure, customizing
+Magento 2, working with events and observers, creating command line interface commands, packaging and installing
+extensions, and best practices to follow when developing extensions.
+
+## 2. Prerequisites
+
+Before diving into extension development, it is important to have a good understanding of PHP and Magento 2. Familiarize
+yourself with the core concepts and architecture of Magento 2, as well as the programming language features of PHP.
+
+To get started with extension development, you will need the following:
+
+- A development environment with Magento 2 installed.
+- A code editor or IDE of your choice.
+- Knowledge of PHP, XML, and JavaScript (depending on the requirements of your extension).
+
+## 3. Extension Structure
+
+A Magento 2 extension follows a specific directory structure that Magento recognizes. Below is an example structure for
+a basic extension called "MyExtension":
+
+```
+MyExtension/
+├── etc/
+│ ├── module.xml
+│ └── ...
+├── Block/
+│ ├── MyBlock.php
+│ └── ...
+├── Controller/
+│ ├── Index/
+│ │ └── Index.php
+│ └── ...
+├── Model/
+│ ├── MyModel.php
+│ └── ...
+├── view/
+│ └── frontend/
+│ ├── layout/
+│ │ ├── myextension_index_index.xml
+│ │ └── ...
+│ ├── templates/
+│ │ ├── myextension.phtml
+│ │ └── ...
+│ └── ...
+└── ...
+```
+
+The `etc` directory contains the module configuration file `module.xml`, where you define the extension's name, version,
+and other important details.
+
+The `Block`, `Controller`, and `Model` directories are where your PHP classes reside. These classes are responsible for
+the business logic of your extension.
+
+The `view` directory is where you define the frontend and backend layouts, templates, and other view-related files for
+your extension.
+
+## 4. Creating an Extension
+
+To create a new extension, follow these steps:
+
+1. Create a new directory inside the `app/code` directory of your Magento installation. For
+ example, `app/code/MyVendor/MyExtension`.
+2. Inside the extension directory, create the necessary subdirectories (`etc`, `Block`, `Controller`, `Model`, `view`,
+ etc.) as per your extension's requirements.
+3. Create the `module.xml` file inside the `etc` directory. This file should contain basic information about your
+ extension, such as its name, version, and dependencies.
+4. Start creating your PHP classes, templates, layout files, etc., as required by your extension.
+
+## 5. Customizing Magento 2
+
+Magento 2 allows you to customize various aspects of the platform by overriding core files. Here are some examples of
+customizations you can make:
+
+### Overriding Templates
+
+To override a template file, create a new template file in your extension's directory and specify the original template
+file to override in your layout XML file. For example:
+
+```xml
+
+
+```
+
+### Overriding Layouts
+
+To override a layout file, create a new layout XML file in your extension's directory and specify the original layout
+file to override. For example:
+
+```xml
+
+
+
+ MyVendor_MyExtension::product/price.phtml
+
+
+```
+
+### Overriding Controllers
+
+To override a controller, create a new controller class in your extension's directory and extend the original controller
+class. For example:
+
+```php
+
+
+To override a model, create a new model class in your extension's directory and extend the original model class. For
+example:
+
+```php
+
+
+Magento 2 provides an event-driven architecture that allows you to listen for specific events and execute custom code.
+This is achieved using events and observers.
+
+### Creating an Observer
+
+To create an observer, you need to define it in the `events.xml` file of your extension and create the corresponding
+observer class. For example:
+
+```xml
+
+
+
+
+```
+
+```php
+
+
+To dispatch an event, you can use the event manager instance in your code. For example:
+
+```php
+eventManager = $eventManager;
+ }
+
+ public function someMethod()
+ {
+ // Dispatching the custom event
+ $this->eventManager->dispatch('myextension_custom_event', ['data' => $someData]);
+ }
+}
+```
+
+### Listening to an Event
+
+To listen to an event, create an observer class as shown in the previous example and define it in the `events.xml` file
+of your extension.
+
+## 7. Creating a Command Line Interface (CLI) Command
+
+Magento 2 allows you to create custom CLI commands that can be executed from the command line. To create a CLI command,
+follow these steps:
+
+1. Create a PHP class that extends the `Command` class from the `Symfony\Component\Console` namespace.
+2. Implement the necessary methods, including `configure` and `execute`, which define the command's configuration and
+ behavior.
+3. Register your command in the `di.xml` file of your extension.
+
+## 8. Packaging and Installing Extensions
+
+To package and install your extension, you need to create a module package. This can be done using the Composer
+packaging mechanism. Refer to the official Magento 2 documentation for detailed instructions on how to package and
+install extensions.
+
+## 9. Testing Extensions
+
+Testing is an integral part of extension development. Magento 2 provides a testing framework that allows you to write
+unit tests, integration tests, and functional tests for your extensions. Follow the official Magento 2 testing
+documentation for guidelines on how to write tests for your extensions.
+
+## 10. Best Practices
+
+Here are some best practices to keep in mind when developing Magento 2 extensions:
+
+- Follow Magento's coding standards and best practices.
+- Use dependency injection to decouple your classes and improve testability.
+- Leverage the Magento 2 cache system to improve performance.
+- Write clear and meaningful documentation for your extension.
+- Regularly update your extension to ensure compatibility with new Magento versions.
+
+Congratulations! You now have a comprehensive understanding of Magento 2 extension development. Start exploring the vast
+possibilities of extending Magento 2 and creating powerful customizations for your clients or projects. Happy coding!
diff --git a/di-xml.md b/di-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/di_xml.md b/di_xml.md
new file mode 100644
index 0000000..0a64e63
--- /dev/null
+++ b/di_xml.md
@@ -0,0 +1,105 @@
+# `di.xml` Reference Documentation
+
+[TOC]
+
+## Introduction
+
+The `di.xml` file is a crucial configuration file in Magento 2 that controls the dependency injection (DI) framework. It
+is used to define and manage dependencies between objects in a Magento installation. This file allows developers to
+configure how objects are instantiated and how they are injected into other objects.
+
+In this reference documentation, we will explore the structure and syntax of the `di.xml` file, and explain how to use
+it to manage dependencies effectively in your Magento 2 project.
+
+## File Location
+
+By default, the `di.xml` file is located in the `etc` directory of a module. The complete path to the file
+is `app/code/{Vendor}/{Module}/etc/di.xml`. For example, if you have a module called `MyModule` developed by
+vendor `MyVendor`, the path to the `di.xml` file would be `app/code/MyVendor/MyModule/etc/di.xml`.
+
+## Syntax
+
+The `di.xml` file uses XML syntax to define and configure dependencies. It consists of a root `` element, which
+contains multiple `` elements. Each `` element represents a class or interface for which dependencies are
+defined. Within a `` element, you can have multiple `` and `` elements.
+
+Here's an example of the basic structure of a `di.xml` file:
+
+```xml
+
+
+
+
+
+
+```
+
+Let's examine each component of this structure in detail.
+
+### `` Element
+
+The `` element is the main building block of the `di.xml` file. It represents a class or interface for which
+dependencies are defined. The `name` attribute of the `` element specifies the fully qualified class or interface
+name.
+
+For example, if we want to configure dependencies for the `Magento\Catalog\Api\ProductRepositoryInterface` interface,
+the `` element would look like this:
+
+```xml
+
+
+
+
+```
+
+### `` Element
+
+The `` element is used to define constructor arguments for a class. Within the `` element, you can
+have multiple `` elements. Each `` element represents a constructor argument.
+
+Here's an example of how to define constructor arguments for the `Magento\Catalog\Api\ProductRepositoryInterface`
+interface:
+
+```xml
+
+
+
+ Magento\Catalog\Model\ProductFactory
+ Magento\Catalog\Model\ResourceModel\Product
+
+
+```
+
+In this example, we define two constructor arguments, namely `productFactory` and `resourceModel`. The `xsi:type`
+attribute specifies the type of the argument, which can be either `object` or `string`. The `name` attribute specifies
+the name of the argument, which can be any valid string.
+
+### `` Element
+
+The `` element is used to define a plugin for a class. Plugins are used to modify the behavior of existing class
+methods by intercepting their execution.
+
+To define a plugin, you need to specify the `` of the class you want to plugin, the `` type (a class that
+implements the plugin), and the name of the method you want to intercept.
+
+Here's an example of how to define a plugin for the `Magento\Catalog\Api\ProductRepositoryInterface` interface:
+
+```xml
+
+
+
+
+```
+
+In this example, we define a plugin with the name `my_plugin`, implemented by the
+class `MyVendor\MyModule\Plugin\ProductRepositoryPlugin`. We also specify the `sortOrder` attribute to control the order
+in which plugins are executed, and the `disabled` attribute to enable or disable the plugin.
+
+## Conclusion
+
+The `di.xml` file is a powerful tool for managing dependencies in Magento 2. By understanding its structure and syntax,
+you can effectively configure and control how objects are instantiated and injected in your Magento project.
+
+This reference documentation has covered the basic components and syntax of the `di.xml` file. We hope that this
+information will help you confidently navigate and utilize the power of the Magento 2 DI framework.
diff --git a/diagrams-to-visually-represent-the-architecture.md b/diagrams-to-visually-represent-the-architecture.md
index e69de29..8cd9eea 100644
--- a/diagrams-to-visually-represent-the-architecture.md
+++ b/diagrams-to-visually-represent-the-architecture.md
@@ -0,0 +1,146 @@
+# Architecture Diagrams Documentation
+
+[TOC]
+
+This documentation provides an overview of architecture diagrams, which are visual representations of a system's
+structure and components. Architecture diagrams are often used to communicate the design and organization of a system to
+stakeholders, developers, and other team members. In the context of this documentation, we will focus on using diagrams
+to represent the architecture of PHP and Magento 2 applications.
+
+## Introduction to Architecture Diagrams
+
+Architecture diagrams provide a high-level view of the structure and components of a system. They help developers and
+stakeholders visualize how different parts of the system interact and communicate with each other. By representing the
+architecture visually, diagrams make it easier to understand complex systems and identify potential design flaws or
+bottlenecks.
+
+In the context of PHP and Magento 2 applications, architecture diagrams can help illustrate the relationships between
+modules, classes, and components. They can also show the flow of data between different parts of the system, such as the
+frontend, backend, and databases.
+
+## Types of Architecture Diagrams
+
+There are several types of architecture diagrams that are commonly used in PHP and Magento 2 applications. Some of the
+most common types include:
+
+### 1. High-Level System Diagrams
+
+High-level system diagrams provide an overview of the entire system and its major components. These diagrams are useful
+for understanding the overall structure and organization of a PHP or Magento 2 application. For example, a high-level
+system diagram for a Magento 2 e-commerce application might include components such as the frontend, backend, database,
+and external services.
+
+### 2. Layered Architecture Diagrams
+
+Layered architecture diagrams show the different layers or tiers of an application and how they interact with each
+other. In PHP and Magento 2 applications, common layers include the presentation layer (frontend), application layer,
+domain layer, and data layer. These diagrams help visualize the separation of concerns and the flow of data between
+layers.
+
+### 3. Component Diagrams
+
+Component diagrams focus on the individual components or modules within an application. These diagrams show how
+different components interact with each other and communicate. In PHP and Magento 2 applications, components can include
+modules, classes, libraries, and external dependencies.
+
+### 4. Sequence Diagrams
+
+Sequence diagrams illustrate the flow of interactions and messages between different components or objects within an
+application. These diagrams are particularly useful for understanding the order of operations and the dependencies
+between different parts of the system. For example, a sequence diagram for a Magento 2 checkout process might show the
+interactions between the frontend, backend, and external payment gateway.
+
+## Common Components in PHP and Magento 2 Architecture Diagrams
+
+When creating architecture diagrams for PHP and Magento 2 applications, there are several common components that are
+often included. Here are some examples:
+
+### 1. Frontend (Presentation Layer)
+
+The frontend component represents the user interface and the interactions between the user and the system. In PHP and
+Magento 2 applications, this often includes HTML, CSS, JavaScript, and PHP templates. The frontend component
+communicates with the backend to retrieve data and update the user interface.
+
+### 2. Backend (Application Layer)
+
+The backend component represents the logic and processing of the application. In PHP and Magento 2 applications, this
+includes PHP classes, controllers, and services. The backend component interacts with the frontend to handle user
+requests, process data, and retrieve data from the database.
+
+### 3. Database (Data Layer)
+
+The database component represents the storage and retrieval of data within the application. In PHP and Magento 2
+applications, common databases include MySQL or Magento's own database abstraction layer. The backend component
+interacts with the database to store and retrieve data.
+
+### 4. External Services and APIs
+
+External services and APIs represent any external systems or services that the application interacts with. In PHP and
+Magento 2 applications, this can include payment gateways, shipping providers, and third-party APIs. These services are
+often represented as separate components in the architecture diagram and show the interactions between the application
+and the external services.
+
+## Examples and Code Snippets
+
+To illustrate the concepts discussed above, here are some examples of architecture diagrams and code snippets that
+represent the architecture of a PHP and Magento 2 application.
+
+**High-Level System Diagram:**
+
+```
++------------------+ +-----------------+ +-----------------+
+| Frontend | | Backend | | Database |
+| |<------>| |<------>| |
+| HTML, CSS, JS | | PHP Classes | | MySQL/Magento |
++------------------+ +-----------------+ +-----------------+
+```
+
+**Layered Architecture Diagram:**
+
+```
++------------------+
+| Presentation |
+| Layer |
++------------------+
+| Application |
+| Layer |
++------------------+
+| Domain |
+| Layer |
++------------------+
+| Data |
+| Layer |
++------------------+
+```
+
+**Component Diagram:**
+
+```
++-----------------+
+| Frontend |
+| Component |
++-----------------+
+| Backend |
+| Component |
++-----------------+
+| Database |
+| Component |
++-----------------+
+```
+
+**Sequence Diagram:**
+
+```
+Frontend -> Backend: Request Product Details
+Backend -> Database: Retrieve Product Data
+Database --> Backend: Return Product Data
+Backend --> Frontend: Render Product Details
+```
+
+## Conclusion
+
+Architecture diagrams are valuable tools for understanding and communicating the structure and components of a system.
+In PHP and Magento 2 applications, architecture diagrams can help developers and stakeholders visualize the
+relationships between modules, classes, and components. By using different types of architecture diagrams, such as
+high-level system diagrams, layered architecture diagrams, component diagrams, and sequence diagrams, it is possible to
+gain a deeper understanding of the system's design and identify potential issues.
diff --git a/directory-structure.md b/directory-structure.md
index e69de29..589f139 100644
--- a/directory-structure.md
+++ b/directory-structure.md
@@ -0,0 +1,77 @@
+# Directory Structure Documentation
+
+[TOC]
+
+## Introduction
+
+This documentation provides an in-depth understanding of the directory structure used in PHP and Magento 2 projects. A
+well-organized and logical directory structure is crucial for efficient development and maintenance of complex
+applications. By following the recommended structure, developers can easily locate, modify, and extend code while
+adhering to best practices. This documentation will outline the main directories, their purposes, and provide specific
+examples and code snippets to illustrate the concepts.
+
+## Root Directory
+
+The root directory of a PHP or Magento 2 project contains essential files and directories necessary for the project to
+function. Let's examine the common files and directories found in this root directory:
+
+1. **app**: This directory contains the majority of your application code and configuration files. It is the heart of
+ the Magento 2 application and contains several subdirectories, including:
+
+ - **code**: This directory is home to your custom PHP modules, organized by vendor name and module name. For
+ instance, if you have a module named "MyModule" developed by "MyVendor," the directory structure would
+ be `app/code/MyVendor/MyModule`.
+
+ - **design**: This directory contains your theme-specific files, such as HTML templates, CSS stylesheets, and
+ JavaScript files. The structure follows the same pattern as the `code` directory, with themes organized by vendor
+ name and theme name.
+
+ - **etc**: The `etc` directory holds configuration files for various aspects of your application, including module
+ configuration, database scripts, and system configuration settings. The structure mirrors the `code` directory,
+ with subdirectories for each module and theme.
+
+ - **i18n**: This directory is used for internationalization (i18n) purposes. It contains translation files for
+ different languages, allowing your application to be easily localized. Translations are organized by module and
+ theme.
+
+ - **view**: The `view` directory is where you define the front-end presentation of your application. It contains
+ subdirectories like `frontend` and `adminhtml` for different areas of your application. Each area has its own set
+ of directories for layout, templates, and web assets.
+
+ - **vendor**: This directory is created when you install dependencies using Composer. It contains all the
+ third-party libraries and modules your project depends on. It is generally recommended not to modify files in this
+ directory directly.
+
+ - **composer.json**: This file specifies the project's dependencies and other metadata required by Composer for
+ managing dependencies and autoloading.
+
+ - **index.php**: The `index.php` file is the entry point of your Magento 2 application. It initializes the Magento
+ framework and processes incoming requests.
+
+ - **.htaccess**: This file contains Apache web server configuration directives, such as URL rewrite rules and
+ security settings. It helps control access to files and directories.
+
+2. **bin**: This directory contains command-line scripts used for various development tasks. For Magento 2 projects, it
+ includes useful scripts like `magento` for running CLI commands and `setup` for installing and upgrading the
+ application.
+
+3. **dev**: The `dev` directory is used for development-specific tools and configurations. It may contain additional
+ scripts, debugging utilities, or profiling tools.
+
+4. **pub**: This directory houses publicly accessible files that are served directly by the web server. It includes
+ files like images, stylesheets, and JavaScript that can be accessed by users. Magento places its static assets in
+ directories like `static`, `media`, and `frontend`.
+
+5. **var**: This directory is used for storing various types of data generated by the application at runtime. It
+ typically includes log files, compiled code, caches, sessions, and generated static files. You should ensure this
+ directory is writable by the web server.
+
+6. **vendor**: Similar to the `vendor` directory in the `app` directory, this directory contains all the third-party
+ libraries and modules your project depends on. It is managed by Composer and should not be modified directly.
+
+## Conclusion
+
+Understanding the directory structure of a PHP or Magento 2 project is crucial for efficient development and
+maintenance. By following the recommended structure outlined in this documentation, developers can easily navigate and
+manage their codebase, resulting in a more organized and maintainable application. Use the provided examples and code
+snippets to gain a deeper understanding of the concepts discussed. Happy coding!
diff --git a/documentation.md b/documentation.md
index 16b294c..d10e17d 100644
--- a/documentation.md
+++ b/documentation.md
@@ -65,38 +65,36 @@
- [Reporting security issues](/docs/{{version}}/reporting-security-issues)
- ## Performance & Scalability
- [Performance best practices](/docs/{{version}}/performance-best-practices)
- - [Caching in Magento 2](/docs/{{version}}/caching-in-magento-2)
- - [Scalability options and recommendations](/docs/{{version}}/scalability-options-and-recommendations)
+ - [Scalability options](/docs/{{version}}/scalability-options-and-recommendations)
- ## Deployment & DevOps
- - [Recommended development workflows](/docs/{{version}}/recommended-development-workflows)
- - [Continuous Integration/Continuous Deployment (CI/CD) with Magento 2](/docs/{{version}}/ci-cd)
- - [Server setup and configuration](/docs/{{version}}/server-setup-and-configuration)
+ - [Development workflows](/docs/{{version}}/recommended-development-workflows)
+ - [CI/CD with Magento 2](/docs/{{version}}/continious-integration-continious-deployment)
+ - [Server setup](/docs/{{version}}/server-setup-and-configuration)
- ## Tutorials & Examples
- [Collection of real-world examples, and step-by-step tutorials](/docs/{{version}}/collection-of-real-world-examples-and-step-by-step-tutorials)
- [Case studies of problem-solving in Magento 2](/docs/{{version}}/case-studies-of-problem-solving-in-magento-2)
- ## Community & Support
- - [How to get help and support](/docs/{{version}}/how-to-get-help-and-support)
- - [How to contribute to the Magento 2 community](/docs/{{version}}/how-to-contribute-to-the-magento-2-community)
+ - [Get help and support](/docs/{{version}}/how-to-get-help-and-support)
+ - [Community Contribution](/docs/{{version}}/how-to-contribute-to-the-magento-2-community)
- ## File References
- - [acl.xml](/docs/{{version}}/acl-xml)
- - [cache.xml](/docs/{{version}}/cache-xml)
- - [cron_groups.xml](/docs/{{version}}/cron-groups-xml)
- - [cron_jobs.xml](/docs/{{version}}/cron-jobs-xml)
- - [db_schema.xml](/docs/{{version}}/db-schema-xml)
- - [di.xml](/docs/{{version}}/di-xml)
- - [email_templates.xml](/docs/{{version}}/email-templates-xml)
- - [events.xml](/docs/{{version}}/events-xml)
- - [events.xml](/docs/{{version}}/events-xml)
- - [extension_attributes.xml](/docs/{{version}}/extension-attributes-xml)
- - [fieldset.xml](/docs/{{version}}/fieldset-xml)
- - [indexer.xml](/docs/{{version}}/indexer-xml)
- - [layout.xml](/docs/{{version}}/layout-xml)
- - [menu.xml](/docs/{{version}}/menu-xml)
- - [routes.xml](/docs/{{version}}/routes-xml)
- - [system.xml](/docs/{{version}}/system-xml)
- - [view.xml](/docs/{{version}}/view-xml)
- - [webapi.xml](/docs/{{version}}/webapi-xml)
- - [widget.xml](/docs/{{version}}/widget-xml)
+ - [acl.xml](/docs/{{version}}/acl_xml)
+ - [cache.xml](/docs/{{version}}/cache_xml)
+ - [cron_jobs.xml](/docs/{{version}}/cron_jobs_xml)
+ - [cron_groups.xml](/docs/{{version}}/cron_groups_xml)
+ - [db_schema.xml](/docs/{{version}}/db_schema_xml)
+ - [di.xml](/docs/{{version}}/di_xml)
+ - [email_templates.xml](/docs/{{version}}/email_templates_xml)
+ - [events.xml](/docs/{{version}}/events_xml)
+ - [extension_attributes.xml](/docs/{{version}}/extension_attributes_xml)
+ - [fieldset.xml](/docs/{{version}}/fieldset_xml)
+ - [indexer.xml](/docs/{{version}}/indexer_xml)
+ - [layout.xml](/docs/{{version}}/layout_xml)
+ - [menu.xml](/docs/{{version}}/menu_xml)
+ - [routes.xml](/docs/{{version}}/routes_xml)
+ - [system.xml](/docs/{{version}}/system_xml)
+ - [view.xml](/docs/{{version}}/view_xml)
+ - [webapi.xml](/docs/{{version}}/webapi_xml)
+ - [widget.xml](/docs/{{version}}/widget_xml)
- ## References
- [Glossary of terms](/docs/{{version}}/glossary-of-terms)
- [Magento 2 coding standards](/docs/{{version}}/magento-2-coding-standards)
diff --git a/email-templates-xml.md b/email-templates-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/email-templates.md b/email-templates.md
index e69de29..a7830ab 100644
--- a/email-templates.md
+++ b/email-templates.md
@@ -0,0 +1,185 @@
+# Email Templates Documentation
+
+[TOC]
+
+## Introduction
+
+Email templates are an essential part of any application that requires sending automated emails. In the context of
+Magento 2, email templates play a crucial role in providing a standardized format for sending transactional emails to
+customers, such as order confirmation, shipment details, and password reset notifications. This documentation aims to
+guide developers on how to create and customize email templates in Magento 2 using PHP.
+
+## 1. Creating Email Templates
+
+Magento 2 provides a straightforward way to create email templates. These templates define the structure and content of
+the email being sent. Email templates are stored in the `app/design/frontend/{Vendor}/{Theme}/Magento_Email/email/`
+directory of your Magento installation.
+
+To create a new email template, follow these steps:
+
+1. In your theme directory, create the `email` directory if it doesn't already exist.
+2. Create a new `.html` file corresponding to the email template you want to create. For
+ example, `order_confirmation.html` for the order confirmation email.
+3. Open the file and define the HTML structure of your email. You can use inline CSS or include external CSS files.
+4. Add placeholders using the following syntax: `{{var placeholder_name}}`. These placeholders will be replaced with
+ dynamic content when the email is sent.
+
+Example of a basic email template:
+
+```html
+
+
+
+
+
+
Order Confirmation
+
Dear {{var customer_name}},
+
Your order {{var order_increment_id}} has been confirmed.
+
+
+```
+
+## 2. Customizing Email Templates
+
+Magento 2 allows you to customize the existing email templates or create new ones based on your specific requirements.
+To customize an email template:
+
+1. Identify the email template you wish to modify. Magento provides a list of predefined templates, such
+ as `sales_email_order_template`, `sales_email_shipment_template`, etc.
+2. In your theme directory, create the `email` directory if it doesn't already exist.
+3. Copy the desired email template file from `vendor/magento/module-email/view/frontend/email/`
+ to `app/design/frontend/{Vendor}/{Theme}/Magento_Email/email/`.
+4. Modify the copied email template as per your requirements.
+
+Example of customizing an existing email template:
+
+```html
+
+
+
+
+
+
New Order Notification
+
Dear Admin,
+
A new order has been placed with the following details:
+
+
+
Order ID: {{var order.increment_id}}
+
Order Total: {{var order.base_grand_total}}
+
+
Please take appropriate action.
+
+
+```
+
+## 3. Variables and Conditions
+
+Email templates in Magento 2 can utilize variables and conditions to dynamically populate content and control the flow
+of the email. These variables provide access to various data associated with the email, such as customer information,
+order details, etc.
+
+To use variables and conditions, wrap them in double curly braces (`{{ }}`). For example, `{{var customer_name}}` is a
+variable that will be replaced with the actual customer name when the email is sent.
+
+Example of using variables and conditions in an email template:
+
+```html
+
+
+
+
+
Order Confirmation
+
+
+{{if customer.is_logged_in}}
+
Dear {{var customer_name}},
+{{else}}
+
Dear Valued Customer,
+{{/if}}
+
+
Your order {{var order_increment_id}} has been confirmed.
+
+
+
+
+
Product
+
Price
+
+ {{foreach order.getItems() as item}}
+
+
{{var item.name}}
+
{{var item.price}}
+
+ {{/foreach}}
+
+
+
+
+```
+
+## 4. Rendering Email Templates
+
+Once you have created or customized an email template, you need to render it within your code to send the email. In
+Magento 2, you can render email templates using the `Magento\Framework\Mail\Template\TransportBuilder` class.
+
+Example of rendering and sending an email using a custom template:
+
+```php
+transportBuilder = $transportBuilder;
+ $this->storeManager = $storeManager;
+ }
+
+ public function sendOrderConfirmationEmail($customerEmail, $order)
+ {
+ $templateOptions = [
+ 'area' => Area::AREA_FRONTEND,
+ 'store' => $this->storeManager->getStore()->getId()
+ ];
+
+ $templateVars = [
+ 'order' => $order,
+ 'customer' => [
+ 'is_logged_in' => true,
+ 'name' => 'John Doe'
+ ]
+ ];
+
+ $from = [
+ 'email' => 'sender@example.com',
+ 'name' => 'Sender Name'
+ ];
+
+ $this->transportBuilder->setTemplateIdentifier('order_confirmation')
+ ->setTemplateOptions($templateOptions)
+ ->setTemplateVars($templateVars)
+ ->setFrom($from)
+ ->addTo($customerEmail)
+ ->getTransport()
+ ->sendMessage();
+ }
+}
+
+```
+
+## 5. Conclusion
+
+Email templates in Magento 2 are powerful tools for creating standard email formats and customizing their content. By
+following the instructions provided in this documentation, you can create, customize, and render email templates that
+meet your specific requirements. Remember to utilize variables and conditions to dynamically populate content and
+control the flow of your emails. Happy coding!
diff --git a/email_templates.md b/email_templates_xml.md
similarity index 99%
rename from email_templates.md
rename to email_templates_xml.md
index 95ce7c3..f9f97c7 100644
--- a/email_templates.md
+++ b/email_templates_xml.md
@@ -1,4 +1,6 @@
-# Email Templates XML Reference Documentation
+# `email_templates.xml` Reference Documentation
+
+[TOC]
This reference documentation provides detailed information on the structure and usage of the `email_templates.xml` file
in Magento 2. It is intended for developers familiar with PHP and Magento 2, and aims to provide authoritative and
diff --git a/events-xml.md b/events-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/events.md b/events.md
index e69de29..d277cbe 100644
--- a/events.md
+++ b/events.md
@@ -0,0 +1,144 @@
+# Event Documentation
+
+[TOC]
+
+This documentation provides a comprehensive guide on events in Magento 2, specifically tailored for developers familiar
+with PHP and Magento 2. Events in Magento 2 allow you to extend the functionality of the core system by injecting custom
+code at specific points in the application flow. By understanding and utilizing events effectively, you can enhance the
+flexibility and modularity of your Magento 2 stores.
+
+## Table of Contents
+
+1. [Introduction to Events](#introduction-to-events)
+2. [Using Events in Magento 2](#using-events-in-magento-2)
+3. [Event Dispatching](#event-dispatching)
+4. [Event Observers](#event-observers)
+5. [Creating Custom Events](#creating-custom-events)
+6. [Summary](#summary)
+
+## Introduction to Events
+
+Events in Magento 2 follow the Observer design pattern, allowing you to observe and respond to specific events triggered
+during the execution of the system. These events serve as hooks, enabling you to inject custom code before, during, or
+after the execution of predefined processes.
+
+## Using Events in Magento 2
+
+To understand how events work in Magento 2, let's explore a basic example. Suppose you want to add a custom logging
+functionality whenever a new customer account is created. By leveraging events, you can achieve this without modifying
+the core code.
+
+### Event Dispatching
+
+In Magento 2, events are dispatched using the `Magento\Framework\Event\ManagerInterface` interface. To dispatch an
+event, you need to follow these steps:
+
+1. Determine the event name to be dispatched. In this example, we will use the event `customer_register_success`.
+
+2. Inject the `ManagerInterface` using dependency injection in your class:
+
+```php
+protected $eventManager;
+
+public function __construct(
+ \Magento\Framework\Event\ManagerInterface $eventManager
+) {
+ $this->eventManager = $eventManager;
+}
+```
+
+3. Dispatch the event at the appropriate place in your code:
+
+```php
+$this->eventManager->dispatch('customer_register_success', ['customer' => $customer]);
+```
+
+By dispatching the event `customer_register_success` and passing the `customer` object, we allow other observers to
+react to this event.
+
+### Event Observers
+
+Observers are responsible for observing events and executing specific actions in response. Magento 2 provides a
+convenient way to define observers using XML configuration. Let's create an observer for our example:
+
+1. Create a new XML file `events.xml` in your module's `etc` directory:
+
+```xml
+
+
+
+
+
+
+```
+
+2. Create the observer class `CustomLogger`:
+
+```php
+namespace Vendor\Module\Observer;
+
+use Magento\Framework\Event\ObserverInterface;
+use Psr\Log\LoggerInterface;
+
+class CustomLogger implements ObserverInterface
+{
+ protected $logger;
+
+ public function __construct(LoggerInterface $logger)
+ {
+ $this->logger = $logger;
+ }
+
+ public function execute(\Magento\Framework\Event\Observer $observer)
+ {
+ $customer = $observer->getData('customer');
+ $this->logger->info('New customer registered: ' . $customer->getName());
+ }
+}
+```
+
+In this example, we observe the `customer_register_success` event and log a message containing the name of the customer
+who registered using the `LoggerInterface`.
+
+### Creating Custom Events
+
+While Magento 2 provides a wide range of predefined events, you can also create custom events to fit your specific
+needs. To create a custom event, follow these steps:
+
+1. Create a new XML file `events.xml` in your module's `etc` directory:
+
+```xml
+
+
+
+
+
+
+```
+
+2. Create the observer class `CustomObserver`:
+
+```php
+namespace Vendor\Module\Observer;
+
+use Magento\Framework\Event\ObserverInterface;
+
+class CustomObserver implements ObserverInterface
+{
+ public function execute(\Magento\Framework\Event\Observer $observer)
+ {
+ // Custom logic goes here
+ }
+}
+```
+
+In this example, we create a custom event named `custom_event` and associate it with the observer `CustomObserver`.
+
+## Summary
+
+Congratulations! You have learned the fundamentals of events in Magento 2. By dispatching and observing events, you can
+extend the core functionality of the system without modifying the core code. This approach enhances modularity and
+allows for easier maintenance and upgrades. Remember to refer to the official Magento 2 documentation for more detailed
+information on specific events and their usage. Happy coding!
diff --git a/events_xml.md b/events_xml.md
new file mode 100644
index 0000000..465689a
--- /dev/null
+++ b/events_xml.md
@@ -0,0 +1,101 @@
+# `events.xml` Reference Documentation
+
+[TOC]
+
+The `events.xml` file in Magento 2 is crucial for creating and handling events within the system. This file is
+responsible for defining the events and the observers which listen to these events.
+
+## Overview
+
+Magento 2's `events.xml` is typically located under the `etc` directory in a module. The directory structure is as
+follows:
+
+```plaintext
+app
+└── code
+ └── Vendor
+ └── Module
+ └── etc
+ ├── events.xml
+ └── ...
+```
+
+## File Structure
+
+The `events.xml` file uses XML format and generally follows this structure:
+
+```xml
+
+
+
+
+
+
+```
+
+- `event_name` refers to the event's unique name, which will be dispatched by Magento.
+- `observer_name` is the unique name of the observer in the context of this event.
+- `Vendor\Module\Observer\ObserverClass` is the class responsible for handling the event when it's triggered.
+- `method` is the method in the ObserverClass that will be called.
+
+## Defining an Event
+
+Defining an event in the `events.xml` file is as simple as adding an `event` tag with a unique `name` attribute. Here's
+an example:
+
+```xml
+
+
+
+
+```
+
+In this case, the `catalog_product_save_after` event is defined, which will trigger after a product is saved.
+
+## Defining an Observer
+
+Defining an observer for the event involves adding an `observer` tag inside the `event` tag. The `instance` attribute
+specifies the class that will handle this event, while the `method` attribute defines the method that will be called.
+
+```xml
+
+
+```
+
+Here, when the `catalog_product_save_after` event triggers, the `execute` method of
+the `Vendor\Module\Observer\ProductSaveAfter` class will be called.
+
+## Observer Class
+
+An observer class typically extends `Magento\Framework\Event\ObserverInterface` and implements the `execute` method,
+where the event logic resides.
+
+Here's a sample observer class:
+
+```php
+getEvent()->getProduct();
+ // Handle the event logic here
+ }
+}
+```
+
+## Conclusion
+
+The `events.xml` file plays a crucial role in Magento 2's event-driven programming paradigm. It facilitates interaction
+between modules and helps maintain code decoupling, making it easier to modify or extend the functionalities. By
+mastering event and observer implementation in Magento 2, developers can build highly flexible and scalable ecommerce
+solutions.
\ No newline at end of file
diff --git a/extension-attributes-xml.md b/extension-attributes-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/extension-use-cases.md b/extension-use-cases.md
index e69de29..fd29936 100644
--- a/extension-use-cases.md
+++ b/extension-use-cases.md
@@ -0,0 +1,70 @@
+# Extension Use Cases Documentation
+
+[TOC]
+
+## Introduction
+
+This documentation provides an overview of the use cases for using extensions in Magento 2. It explains what extensions are, why they are important, and provides concrete examples and code snippets to illustrate the concepts discussed. This documentation assumes that you have some familiarity with programming, specifically PHP and Magento 2.
+
+## What are Extensions?
+
+Extensions, also known as modules, are a fundamental part of Magento 2's architecture. They allow you to add new features, modify existing functionality, and customize the behavior of your Magento store. Extensions can be created by Magento or third-party developers and are typically distributed as installable packages.
+
+Extensions follow a modular approach, where each extension represents a self-contained unit of functionality. This modular design allows for easy customization and flexibility, as different extensions can be added or removed without affecting the core functionality of Magento.
+
+## Why Use Extensions?
+
+Using extensions in Magento 2 offers several benefits, including:
+
+1. **Increased functionality**: Extensions allow you to extend the core functionality of Magento, adding new features and capabilities to your store. For example, you can use an extension to integrate your store with a popular payment gateway or add a new shipping method.
+
+2. **Customization**: Extensions enable you to customize the behavior and appearance of your Magento store to align with your specific business requirements. You can modify existing functionality or create completely new functionality using extensions.
+
+3. **Time and cost savings**: By leveraging existing extensions, you can save valuable development time and reduce costs. Rather than building everything from scratch, you can take advantage of pre-built extensions that already provide the functionality you need.
+
+4. **Community-driven innovation**: The Magento community is vibrant and active, with a vast ecosystem of developers constantly creating and maintaining extensions. By using extensions, you can tap into this community-driven innovation and leverage the work of other developers.
+
+## Use Cases
+
+Here are a few common use cases for using extensions in Magento 2, along with code snippets to illustrate the concepts:
+
+### Payment Gateway Integration
+
+Many extensions provide integration with popular payment gateways, allowing you to accept payments from various providers. For example, let's say you want to add support for the Stripe payment gateway. You can install the "Stripe Payment" extension, which provides the necessary integration code. Once installed, you can configure the extension and start accepting payments through Stripe.
+
+```php
+// Code snippet to configure the Stripe Payment extension
+$stripeApiKey = 'your-api-key';
+$stripePaymentConfig = $this->getConfig('payment/stripe');
+$stripePaymentConfig->setApiKey($stripeApiKey);
+```
+
+### Product Recommendations
+
+Extensions can also be used to enhance your store's product recommendation capabilities. Suppose you want to improve the product suggestion algorithm on your homepage. You can install an extension like "Product Recommendations Pro," which offers advanced recommendation algorithms. After installation, you can configure the extension to customize the recommendation logic and display personalized product suggestions to your customers.
+
+```php
+// Code snippet to display personalized product recommendations
+$recommendedProducts = $this->getRecommendedProducts('homepage');
+foreach ($recommendedProducts as $product) {
+ echo $product->getName();
+ echo $product->getPrice();
+ // Display other product details
+}
+```
+
+### Storefront Customization
+
+Extensions also enable you to customize the appearance and behavior of your storefront. Let's say you want to change the layout and styling of the product listing page. You can install an extension like "Custom Product Listing Layout" and use its configuration options to modify the layout and styling of the product listing page.
+
+```php
+// Code snippet to modify the product listing layout
+$productListingConfig = $this->getConfig('custom_product_listing');
+$productListingConfig->setColumnCount(4);
+$productListingConfig->setShowPrice(true);
+$productListingConfig->setShowAddToCartButton(false);
+```
+
+## Conclusion
+
+Extensions are a powerful tool in Magento 2 that allow you to extend the core functionality, customize your store, and enhance its capabilities. By leveraging existing extensions, you can save time and effort while benefiting from the constant innovation of the Magento community. Use the provided code snippets and examples to explore various use cases and start enhancing your Magento store today.
diff --git a/extension_attributes.md b/extension_attributes.md
new file mode 100644
index 0000000..d71a000
--- /dev/null
+++ b/extension_attributes.md
@@ -0,0 +1,142 @@
+# Extension Attributes Reference Documentation
+
+[TOC]
+
+## Introduction
+
+Extension attributes in Magento 2 provide a way to extend the functionality of existing data structures, such as models
+or entities, without modifying the original code. This allows developers to add custom data fields to existing objects,
+enabling them to store additional information relevant to their specific business requirements.
+
+This reference documentation aims to provide a comprehensive overview of extension attributes in Magento 2, including
+how to define, use, and manipulate them. By following the guidelines and examples provided, developers will be able to
+effectively leverage extension attributes to enhance their Magento 2 projects.
+
+## 1. Defining Extension Attributes
+
+Extension attributes are defined in `extension_attributes.xml` files located in the `etc` directory of a module. These
+XML files specify the structure and behavior of the extension attributes. Each `extension_attributes.xml` file can
+define extension attributes for one or more data structures.
+
+To define an extension attribute, you need to specify its name, type, and the data structure it extends.
+The `extension_attributes.xml` file follows a hierarchical structure, with a root `` element
+containing individual `` elements for each attribute.
+
+Here's an example of an `extension_attributes.xml` file defining an extension attribute named `custom_attribute` for
+the `Magento\Catalog\Api\Data\ProductInterface` data structure:
+
+```xml
+
+
+
+
+
+
+```
+
+In this example, the extension attribute `custom_attribute` is defined as a `string` type. It can now be used to store
+additional custom data for products.
+
+## 2. Using Extension Attributes
+
+Once extension attributes are defined, they can be used to store and retrieve custom data for the data structures they
+extend. To access an extension attribute, you need to use the corresponding getter and setter methods provided by the
+Magento 2 framework.
+
+For instance, using the `custom_attribute` extension attribute defined in the previous example, you can retrieve and set
+its value for a product object as follows:
+
+```php
+/** @var Magento\Catalog\Api\Data\ProductInterface $product */
+$product->setCustomAttribute('custom_attribute', 'some value');
+
+// Get the value of the extension attribute
+$value = $product->getCustomAttribute('custom_attribute')->getValue();
+```
+
+It is important to note that extension attributes are not automatically persisted to the database. You need to manually
+save the object containing the extension attribute for the changes to take effect.
+
+## 3. Manipulating Extension Attributes
+
+Extension attributes can also be manipulated using plugins and observers. Plugins allow you to modify the behavior of
+getter and setter methods, while observers enable you to react to changes in extension attribute values.
+
+To create a plugin for an extension attribute, you need to define a class that implements
+the `Magento\Framework\Api\ExtensionAttributesInterface` interface. This class should contain the desired logic for the
+plugin.
+
+Here's an example of a plugin that modifies the behavior of the `getCustomAttribute` method for the `custom_attribute`
+extension attribute:
+
+```php
+use Magento\Framework\Api\ExtensionAttributesInterface;
+
+class CustomAttributePlugin
+{
+ public function afterGetCustomAttribute(
+ ExtensionAttributesInterface $subject,
+ $result,
+ $attributeCode
+ ) {
+ // Modify the result based on custom logic
+ return $modifiedResult;
+ }
+}
+```
+
+Observers, on the other hand, allow you to react to changes in extension attribute values by defining observers in the
+module's `events.xml` file. These observers are triggered when extension attributes are modified, allowing you to
+perform additional actions.
+
+## 4. Code Examples
+
+To provide further understanding and practical guidance, here are a few code examples showcasing the usage of extension
+attributes in Magento 2:
+
+1. Retrieving and setting an extension attribute for a product:
+
+```php
+/** @var Magento\Catalog\Api\Data\ProductInterface $product */
+$product->setCustomAttribute('custom_attribute', 'some value');
+
+// Get the value of the extension attribute
+$value = $product->getCustomAttribute('custom_attribute')->getValue();
+```
+
+2. Creating a plugin for an extension attribute:
+
+```php
+use Magento\Framework\Api\ExtensionAttributesInterface;
+
+class CustomAttributePlugin
+{
+ public function afterGetCustomAttribute(
+ ExtensionAttributesInterface $subject,
+ $result,
+ $attributeCode
+ ) {
+ // Modify the result based on custom logic
+ return $modifiedResult;
+ }
+}
+```
+
+3. Defining an observer for extension attribute changes:
+
+```xml
+
+
+
+
+
+
+```
+
+In conclusion, extension attributes in Magento 2 offer a powerful way to extend existing data structures and store
+additional custom data. By following the guidelines and examples provided in this reference documentation, developers
+will be able to effectively leverage extension attributes in their Magento 2 projects, enhancing the flexibility and
+functionality of their applications.
diff --git a/extension_attributes_xml.md b/extension_attributes_xml.md
new file mode 100644
index 0000000..33871c9
--- /dev/null
+++ b/extension_attributes_xml.md
@@ -0,0 +1,90 @@
+# `extension_attributes.xml` Reference Documentation
+
+[TOC]
+
+The `extension_attributes.xml` file is an essential part of Magento 2, providing a robust way to extend Magento service
+contracts' data. Extension attributes are custom attributes that are added to entities such as products, orders,
+customers, etc.
+
+## Overview
+
+The `extension_attributes.xml` file is typically located under the `etc` directory in a module:
+
+```plaintext
+app
+└── code
+ └── Vendor
+ └── Module
+ └── etc
+ ├── extension_attributes.xml
+ └── ...
+```
+
+## File Structure
+
+The structure of the `extension_attributes.xml` file in Magento 2 follows this pattern:
+
+```xml
+
+
+
+
+
+
+```
+
+- `for` specifies the interface for which the extension attribute is added.
+- `code` is the unique name for the extension attribute.
+- `type` is the data type for the extension attribute.
+
+## Defining Extension Attributes
+
+Defining an extension attribute requires specifying the `for` attribute, which mentions the Interface against which we
+are defining the attribute. The `code` and `type` define the attribute itself.
+
+Here is an example of adding a custom attribute to the Product entity:
+
+```xml
+
+
+
+
+```
+
+## Accessing Extension Attributes
+
+Extension attributes can be accessed and set via the entity's extension attributes object. Here's an example using the
+product entity:
+
+```php
+productRepository->get('product_sku');
+$extensionAttributes = $product->getExtensionAttributes();
+
+// Get the value of the custom_attribute
+$customAttributeValue = $extensionAttributes->getCustomAttribute();
+
+// Set a value for the custom_attribute
+$extensionAttributes->setCustomAttribute('New Value');
+$product->setExtensionAttributes($extensionAttributes);
+
+$this->productRepository->save($product);
+```
+
+## Best Practices
+
+1. Extension attributes should be added for service contract interfaces only. Do not use them for other classes or
+ interfaces.
+
+2. It's best not to use extension attributes as a substitute for custom attributes. Use them when you need to add data
+ to an entity that does not naturally belong to it.
+
+3. Keep in mind that extension attributes are not persisted automatically. Developers need to handle the persistence (
+ saving/loading) of these attributes manually.
+
+## Conclusion
+
+The `extension_attributes.xml` file is a powerful tool in Magento 2, enabling developers to extend data for service
+contract interfaces. Proper understanding and usage of extension attributes contribute to building flexible and
+extendable custom modules.
diff --git a/fieldset-xml.md b/fieldset-xml.md
deleted file mode 100644
index e69de29..0000000
diff --git a/fieldset_xml.md b/fieldset_xml.md
new file mode 100644
index 0000000..26bce62
--- /dev/null
+++ b/fieldset_xml.md
@@ -0,0 +1,181 @@
+# `fieldset.xml` Reference Documentation
+
+[TOC]
+
+## Introduction
+
+The `fieldset.xml` file is an important configuration file in the Magento 2 framework. It is used to define and modify
+the structure of data fields retrieved from database tables and models. This documentation will guide you through the
+different elements and attributes used in `fieldset.xml` and their corresponding functionalities. By understanding and
+correctly using `fieldset.xml`, you can customize and extend the data fields in your Magento 2 application.
+
+## File Structure
+
+The `fieldset.xml` file follows a specific structure that consists of one or more `