fix wrong web words

Author: AmirHkrg

src/cache.md

@@ -5,7 +5,7 @@
 
 Some of the data retrieval or processing tasks performed by your application could be CPU intensive or take several seconds to complete. When this is the case, it is common to cache the retrieved data for a time so it can be retrieved quickly on subsequent requests for the same data. The cached data is usually stored in a very fast data store such as [Memcached](https://memcached.org) or [Redis](https://redis.io).
 
-Thankfully, LaraGram provides an expressive, unified API for various cache backends, allowing you to take advantage of their blazing fast data retrieval and speed up your web application.
+Thankfully, LaraGram provides an expressive, unified API for various cache backends, allowing you to take advantage of their blazing fast data retrieval and speed up your bot application.
 
 <a name="configuration"></a>
 ## Configuration
@@ -407,7 +407,7 @@ Cache::lock('foo', 10)->block(5, function () {
 <a name="managing-locks-across-processes"></a>
 ### Managing Locks Across Processes
 
-Sometimes, you may wish to acquire a lock in one process and release it in another process. For example, you may acquire a lock during a web request and wish to release the lock at the end of a queued job that is triggered by that request. In this scenario, you should pass the lock's scoped "owner token" to the queued job so that the job can re-instantiate the lock using the given token.
+Sometimes, you may wish to acquire a lock in one process and release it in another process. For example, you may acquire a lock during a bot request and wish to release the lock at the end of a queued job that is triggered by that request. In this scenario, you should pass the lock's scoped "owner token" to the queued job so that the job can re-instantiate the lock using the given token.
 
 In the example below, we will dispatch a queued job if a lock is successfully acquired. In addition, we will pass the lock's owner token to the queued job via the lock's `owner` method:
 

src/container.md

@@ -269,7 +269,7 @@ class PhotoController extends Controller
 }
 ```
 
-In addition to the `Storage` attribute, LaraGram offers `Auth`, `Cache`, `Config`, `Context`, `DB`, `Give`, `Log`, `ListenParameter`, and [Tag](#tagging) attributes:
+In addition to the `Storage` attribute, LaraGram offers `Cache`, `Config`, `Context`, `DB`, `Give`, `Log`, `ListenParameter`, and [Tag](#tagging) attributes:
 
 ```php
 <?php
@@ -296,7 +296,6 @@ use Psr\Log\LoggerInterface;
 class PhotoController extends Controller
 {
     public function __construct(
-        #[Auth('web')] protected Guard $auth,
         #[Cache('redis')] protected Repository $cache,
         #[Config('app.timezone')] protected string $timezone,
         #[Context('uuid')] protected string $uuid,

src/database.md

@@ -3,7 +3,7 @@
 <a name="introduction"></a>
 ## Introduction
 
-Almost every modern web application interacts with a database. LaraGram makes interacting with databases extremely simple across a variety of supported databases using raw SQL, a [fluent query builder](/queries.md), and the [Eloquent ORM](/eloquent.md). Currently, LaraGram provides first-party support for five databases:
+Almost every modern bot application interacts with a database. LaraGram makes interacting with databases extremely simple across a variety of supported databases using raw SQL, a [fluent query builder](/queries.md), and the [Eloquent ORM](/eloquent.md). Currently, LaraGram provides first-party support for five databases:
 
 <div class="content-list" markdown="1">
 
@@ -316,7 +316,7 @@ class AppServiceProvider extends ServiceProvider
 <a name="monitoring-cumulative-query-time"></a>
 ### Monitoring Cumulative Query Time
 
-A common performance bottleneck of modern web applications is the amount of time they spend querying databases. Thankfully, LaraGram can invoke a closure or callback of your choice when it spends too much time querying the database during a single request. To get started, provide a query time threshold (in milliseconds) and closure to the `whenQueryingForLongerThan` method. You may invoke this method in the `boot` method of a [service provider](/providers.md):
+A common performance bottleneck of modern bot applications is the amount of time they spend querying databases. Thankfully, LaraGram can invoke a closure or callback of your choice when it spends too much time querying the database during a single request. To get started, provide a query time threshold (in milliseconds) and closure to the `whenQueryingForLongerThan` method. You may invoke this method in the `boot` method of a [service provider](/providers.md):
 
 ```php
 <?php

src/installation.md

@@ -10,7 +10,7 @@ If you're familiar with LaraGram, you'll feel right at home with Laravel — and
 
 LaraGram strives to provide an amazing developer experience while providing powerful features such as thorough dependency injection, an expressive database abstraction layer, queues and scheduled jobs, unit and integration testing, and more.
 
-Whether you are new to PHP web frameworks or have years of experience, LaraGram is a framework that can grow with you. We'll help you take your first steps as a bot developer or give you a boost as you take your expertise to the next level. We can't wait to see what you build.
+Whether you are new to PHP bot frameworks or have years of experience, LaraGram is a framework that can grow with you. We'll help you take your first steps as a bot developer or give you a boost as you take your expertise to the next level. We can't wait to see what you build.
 
 <a name="why-laragram"></a>
 ### Why LaraGram?
@@ -138,7 +138,7 @@ php laragram migrate
 <a name="directory-configuration"></a>
 ### Directory Configuration
 
-LaraGram should always be served out of the root of the "web directory" configured for your web server. You should not attempt to serve a LaraGram application out of a subdirectory of the "web directory". Attempting to do so could expose sensitive files present within your application.
+LaraGram should always be served out of the root of the "bot directory" configured for your web server. You should not attempt to serve a LaraGram application out of a subdirectory of the "bot directory". Attempting to do so could expose sensitive files present within your application.
 
 <a name="next-steps"></a>
 ## Next Steps

src/listening.md

@@ -17,7 +17,7 @@ Bot::onText('hello', function (Request $request) {
 <a name="the-default-listen-files"></a>
 ### The Default Listen Files
 
-All LaraGram listens are defined in your listen files, which are located in the `listens` directory. These files are automatically loaded by LaraGram using the configuration specified in your application's `bootstrap/app.php` file. The `listens/bot.php` file defines listens that are for your web interface. These listens are assigned the `bot` [middleware group](/middleware.md#laragrams-default-middleware-groups), which provides features like scope limiter.
+All LaraGram listens are defined in your listen files, which are located in the `listens` directory. These files are automatically loaded by LaraGram using the configuration specified in your application's `bootstrap/app.php` file. The `listens/bot.php` file defines listens that are for your bot interface. These listens are assigned the `bot` [middleware group](/middleware.md#laragrams-default-middleware-groups), which provides features like scope limiter.
 
 For most applications, you will begin by defining listens in your `listens/bot.php` file. The listens defined in `listens/bot.php` may be accessed by entering the defined listen's update in your bot. For example, you may access the following listen by sending a `hello`:
 
@@ -211,7 +211,7 @@ However, sometimes you may want to define an entirely new file to contain a subs
 use LaraGram\Support\Facades\Bot;
 
 ->withListening(
-    web: __DIR__.'/../listens/bot.php',
+    bot: __DIR__.'/../listens/bot.php',
     commands: __DIR__.'/../listens/console.php',
     then: function () {
         Bot::middleware('scope:groups')

src/middleware.md

@@ -224,7 +224,7 @@ Listen::middleware(['group-name'])->group(function () {
 <a name="laragrams-default-middleware-groups"></a>
 #### LaraGram's Default Middleware Groups
 
-LaraGram includes predefined `bot` middleware groups that contain common middleware you may want to apply to your web and API listens. Remember, LaraGram automatically applies these middleware groups to the corresponding `listens/bot.php` files:
+LaraGram includes predefined `bot` middleware groups that contain common middleware you may want to apply to your bot listens. Remember, LaraGram automatically applies these middleware groups to the corresponding `listens/bot.php` files:
 
 <div class="overflow-auto">
 

src/queues.md

@@ -3,7 +3,7 @@
 <a name="introduction"></a>
 ## Introduction
 
-While building your web application, you may have some tasks, such as parsing and storing an uploaded CSV file, that take too long to perform during a typical request. Thankfully, LaraGram allows you to easily create queued jobs that may be processed in the background. By moving time intensive tasks to a queue, your application can respond to web requests with blazing speed and provide a better user experience to your customers.
+While building your bot application, you may have some tasks, such as parsing and storing an uploaded CSV file, that take too long to perform during a typical request. Thankfully, LaraGram allows you to easily create queued jobs that may be processed in the background. By moving time intensive tasks to a queue, your application can respond to bot requests with blazing speed and provide a better user experience to your customers.
 
 LaraGram queues provide a unified queueing API across a variety of different queue backends, [Redis](https://redis.io), or even a relational database.
 
@@ -1567,7 +1567,7 @@ Bus::chain([
 <a name="adding-jobs-to-batches"></a>
 ### Adding Jobs to Batches
 
-Sometimes it may be useful to add additional jobs to a batch from within a batched job. This pattern can be useful when you need to batch thousands of jobs which may take too long to dispatch during a web request. So, instead, you may wish to dispatch an initial batch of "loader" jobs that hydrate the batch with even more jobs:
+Sometimes it may be useful to add additional jobs to a batch from within a batched job. This pattern can be useful when you need to batch thousands of jobs which may take too long to dispatch during a bot request. So, instead, you may wish to dispatch an initial batch of "loader" jobs that hydrate the batch with even more jobs:
 
 ```php
 $batch = Bus::batch([

src/surge.md

@@ -141,7 +141,7 @@ server {
 <a name="watching-for-file-changes"></a>
 ### Watching for File Changes
 
-Since your application is loaded in memory once when the Surge server starts, any changes to your application's files will not be reflected when you refresh your browser. For example, listen definitions added to your `listens/web.php` file will not be reflected until the server is restarted. For convenience, you may use the `--watch` flag to instruct Surge to automatically restart the server on any file changes within your application:
+Since your application is loaded in memory once when the Surge server starts, any changes to your application's files will not be reflected when you refresh your browser. For example, listen definitions added to your `listens/bot.php` file will not be reflected until the server is restarted. For convenience, you may use the `--watch` flag to instruct Surge to automatically restart the server on any file changes within your application:
 
 ```shell
 php laragram surge:start --watch

src/temple8.md

@@ -1085,7 +1085,7 @@ When a prefix is provided, components within that "namespace" may be rendered by
 <a name="layouts-using-components"></a>
 ### Layouts Using Components
 
-Most web applications maintain the same general layout across various pages. It would be incredibly cumbersome and hard to maintain our application if we had to repeat the entire layout in every template we create. Thankfully, it's convenient to define this layout as a single [Temple8 component](#components) and then use it throughout our application.
+Most bot applications maintain the same general layout across various pages. It would be incredibly cumbersome and hard to maintain our application if we had to repeat the entire layout in every template we create. Thankfully, it's convenient to define this layout as a single [Temple8 component](#components) and then use it throughout our application.
 
 <a name="applying-the-layout-component"></a>
 #### Applying the Layout Component
@@ -1136,7 +1136,7 @@ Bot::onText('/tasks', function () {
 
 Layouts may also be created via "template inheritance". This was the primary way of building applications prior to the introduction of [components](#components).
 
-To get started, let's take a look at a simple example. First, we will examine a page layout. Since most web applications maintain the same general layout across various pages, it's convenient to define this layout as a single Temple8 template:
+To get started, let's take a look at a simple example. First, we will examine a page layout. Since most bot applications maintain the same general layout across various pages, it's convenient to define this layout as a single Temple8 template:
 
 ```blade
 <!-- app/templates/layouts/app.t8.php -->

src/validation.md

@@ -112,7 +112,7 @@ $rules = [
 
 So, what if the incoming request fields do not pass the given validation rules? As mentioned previously, LaraGram will automatically redirect the user back to their previous location. In addition, all of the validation errors will automatically be [putted to the cache](/cache.md#storing-items-in-the-cache).
 
-An `$errors` variable is shared with all of your application's templates by the `LaraGram\View\Middleware\ShareErrorsFromSession` middleware, which is provided by the `web` middleware group. When this middleware is applied an `$errors` variable will always be available in your templates, allowing you to conveniently assume the `$errors` variable is always defined and can be safely used. The `$errors` variable will be an instance of `LaraGram\Support\MessageBag`. For more information on working with this object, [check out its documentation](#working-with-error-messages).
+An `$errors` variable is shared with all of your application's templates, which is provided by the `bot` middleware group. When this middleware is applied an `$errors` variable will always be available in your templates, allowing you to conveniently assume the `$errors` variable is always defined and can be safely used. The `$errors` variable will be an instance of `LaraGram\Support\MessageBag`. For more information on working with this object, [check out its documentation](#working-with-error-messages).
 
 So, in our example, the user will be redirected to our controller's `create` method when validation fails, allowing us to display the error messages in the view:
 
@@ -1940,7 +1940,7 @@ $validator = Validator::make($inputs, [
 ]);
 ```
 
-Let's assume our web application is for game collectors. If a game collector registers with our application and they own more than 100 games, we want them to explain why they own so many games. For example, perhaps they run a game resale shop, or maybe they just enjoy collecting games. To conditionally add this requirement, we can use the `sometimes` method on the `Validator` instance.
+Let's assume our bot application is for game collectors. If a game collector registers with our application and they own more than 100 games, we want them to explain why they own so many games. For example, perhaps they run a game resale shop, or maybe they just enjoy collecting games. To conditionally add this requirement, we can use the `sometimes` method on the `Validator` instance.
 
 ```php
 use LaraGram\Support\Fluent;