DEV Community: Alhiane Lahcen

Disabling WordPress plugins for one browser only, on a live site

Alhiane Lahcen — Wed, 11 Nov 2026 12:00:00 +0000

"Deactivate all plugins" is the first step in almost every WordPress troubleshooting guide. On a live store it is also the step that breaks checkout for every real customer while you test.

There is another way: turn plugins off only for your own browser. Visitors, search engines and other admins keep seeing the normal site. Nothing in the database changes.

This post shows how that works, with a small must-use plugin you can read in five minutes, and the one trap that can quietly wipe a site's active plugin list.

Where WordPress decides which plugins load

On every request, WordPress reads the active_plugins option and loads each plugin in that list. That read goes through get_option(), and every get_option() call runs the filter option_{$name}.

So if code runs before normal plugins load, it can change the list for this one request:

add_filter( 'option_active_plugins', function ( $plugins ) {
    return array_diff( $plugins, array( 'some-plugin/some-plugin.php' ) );
} );

Must-use plugins (files in wp-content/mu-plugins/) load before normal plugins, so they are the right place for this filter.

On multisite, network-activated plugins live in a different option, active_sitewide_plugins, filtered with site_option_active_sitewide_plugins. Handle both if you support multisite.

Scoping it to one browser

The filter above applies to everyone. We only want it for one person.

The obvious idea is "only when the current user is an admin". That does not work here: when must-use plugins run, WordPress has not loaded the user functions yet (pluggable.php loads after plugins). You cannot call is_user_logged_in() this early.

So use a cookie instead:

When the admin starts a test session (from a normal admin page, where you can check capabilities and a nonce), create a random token.
Store a hash of the token, an expiry time and the list of plugins to skip in an option.
Send the raw token to the admin's browser as a cookie.
In the must-use plugin, compare the cookie's hash to the stored hash. Only filter when they match.

<?php
/**
 * Plugin Name: One-browser plugin filter (demo)
 * Description: Skips selected plugins for one browser session only.
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

const OBPF_COOKIE = 'obpf_session';
const OBPF_OPTION = 'obpf_session';

function obpf_current_session() {
    static $session = null;
    static $checked = false;

    if ( $checked ) {
        return $session;
    }
    $checked = true;

    if ( empty( $_COOKIE[ OBPF_COOKIE ] ) ) {
        return null;
    }

    // Shape: [ 'token_hash' => string, 'expires' => int, 'disabled' => string[] ]
    $stored = get_option( OBPF_OPTION );
    if ( ! is_array( $stored ) || time() > (int) $stored['expires'] ) {
        return null;
    }

    $token = (string) wp_unslash( $_COOKIE[ OBPF_COOKIE ] );
    if ( ! hash_equals( $stored['token_hash'], hash( 'sha256', $token ) ) ) {
        return null;
    }

    $session = $stored;
    return $session;
}

add_filter( 'option_active_plugins', function ( $plugins ) {
    $session = obpf_current_session();
    if ( ! $session ) {
        return $plugins;
    }
    return array_values( array_diff( (array) $plugins, (array) $session['disabled'] ) );
} );

Why a hash and hash_equals()? If the database leaks, the stored value alone is not enough to start someone else's session, and the comparison does not leak timing information.

Anyone without the cookie gets the unfiltered list. That includes visitors, crawlers, and other admins on their own browsers.

The trap: saving the filtered list

This is the part that bites people.

While your session is active, get_option( 'active_plugins' ) returns the shortened list. Now imagine you activate or deactivate any plugin during the session. WordPress reads the active list (shortened), changes it, and saves it back with update_option().

The plugins you were "only hiding" are now really deactivated, for everyone.

Ways to avoid it:

Block plugin changes during a session. Disable activate/deactivate/update/delete actions on the Plugins screen while the cookie is valid, and show a notice that says why.
Or don't filter on those requests. Skip the filter on plugins.php and update.php actions. This is harder to get fully right, because other code can also write the option.
Test it. Start a session, try to activate a plugin, then check the real option from a second browser or with WP-CLI: wp option get active_plugins.

Caching

Page caches are the other place this can go wrong.

The admin is logged in, and most page caches skip logged-in users, so the admin usually sees uncached pages. Check your cache does this, or add the session cookie to its bypass list.
The bigger risk is the reverse: a filtered page (missing a plugin's output) getting cached and served to visitors. A cookie bypass rule prevents this.
The persistent object cache is safe. The filter runs after the value is read, so the cached active_plugins value itself is never changed.

Safety exits

If you skip the wrong plugin, you can lock yourself out of wp-admin. For example, a security or login plugin, or a plugin that another plugin depends on. You need ways out that do not depend on the admin area working:

A clear Exit button in the admin bar that deletes the option and the cookie.
An emergency link that works when you are logged out. Because the must-use plugin runs before authentication, it can check for a secret URL parameter and end the session. Show the link to the admin when the session starts, so they can copy it.
An expiry time. Sessions should end by themselves. Pair a short idle timeout with a hard maximum.
Last resort: delete the session option with WP-CLI or phpMyAdmin, or rename the must-use plugin file over FTP.

What this method can't test

Because it works by filtering the plugin list, some things stay out of reach:

The theme. It loads through a different path.
Must-use plugins and drop-ins (object-cache.php, advanced-cache.php, db.php). They load before or outside the normal plugin list.
Server settings: PHP version, memory limit, .htaccess or nginx rules.

If a problem survives with every normal plugin skipped, look at those next.

Tools that do this for you

You don't have to write this yourself:

Health Check & Troubleshooting: its troubleshooting mode turns off plugins for your session only. You choose which ones to turn back on.
Culprit Finder: a free, GPL plugin I built (disclosure: I'm the author). It switches plugins off only for your own logged-in browser and never changes the active plugin list. It then runs a binary search to find the plugin causing the problem, or the two plugins that only break together. It has an Exit button, an emergency link that works logged out, and it stops by itself after 60 idle minutes (3 hours max). No account, no tracking, no external requests.

Summary

option_active_plugins in a must-use plugin lets you change the plugin list for one request.
Scope it with a hashed cookie token, not a user check. User functions aren't loaded yet.
Never let the filtered list be saved back. Block plugin changes during a session.
Make sure page caches never store or serve the filtered version.
Build exits that work even when wp-admin doesn't.

Have you used a per-session approach on a production site? I'd like to hear what broke, or what you'd add to the safety list.

Writing a WordPress plugin bug report that support teams can actually act on

Alhiane Lahcen — Mon, 09 Nov 2026 20:46:49 +0000

If you have ever posted in a WordPress plugin support forum, you know the first reply by heart:

"Can you share your System Info, the steps to reproduce, and confirm the issue happens with only our plugin active?"

That reply costs you a day, sometimes three. The support person isn't stalling. They can't do anything with "checkout is broken since the update, please fix ASAP." They need to see the bug happen on their own test site, and your report is the only map they have.

I build and support a WordPress plugin, and I read a lot of these threads. The ones that get fixed fast all have the same shape. Here it is.

1. One sentence: what you expected vs. what happened

Not "it doesn't work." Two halves:

Expected: "Clicking Place order with Stripe should go to the thank-you page."
Actual: "The spinner runs for about 10 seconds, then 'There was an error processing your order' appears. No order is created."

Copy any error text exactly. Screenshots are good. The exact text is better, because people can search it.

2. Steps to reproduce, from a clean start

Write them like a recipe someone else will follow on a fresh install:

Add any simple product to the cart.
Go to /checkout/ as a logged-out visitor.
Choose Stripe, use test card 4242 4242 4242 4242.
Click Place order.

Then add one line: does it happen every time, or sometimes? "3 out of 5 tries" is a useful fact. Bugs that happen "sometimes" are often caching, cron or race conditions, and the developer will look in a different place.

Also note who sees it: logged-out visitors only? Admins only? One browser? That one detail can cut the search in half.

3. Versions, all of them

The developer will try to rebuild your setup. Give them the numbers:

WordPress version
PHP version
The plugin's version (and the version where it last worked, if you know it)
Active theme and its version
Hosting type if relevant (managed host, object cache, CDN)

You don't have to type this. Tools → Site Health → Info → Copy site info to clipboard gives you all of it. Paste it inside a collapsible block or a code block if the forum supports it. Remove anything private first (the copy is plain text, so read it before posting).

4. Prove it's this plugin (or name the pair)

This is the part most reports skip, and it's the one that matters most.

Every plugin developer has spent hours on a bug that turned out to come from a different plugin. So the first thing they will ask is: does it still happen when only our plugin (plus WooCommerce, if it's a Woo extension) is active, with a default theme?

If you can answer that before they ask, your thread jumps the queue. There are a few ways to get the answer:

On a staging copy: deactivate everything except the plugin in question, switch to a default theme like Twenty Twenty-Five, test. Then turn plugins back on in halves until the bug returns. Halving is much faster than one by one: 30 plugins take about 5 to 7 rounds, not 30.
On the live site, without breaking it for visitors: the Health Check & Troubleshooting plugin can disable plugins for your logged-in session only.
With a conflict tool: I built Culprit Finder for exactly this step (disclosure: I'm the author). It runs the halving for your browser only, asks "is the problem still there?" after each round, and at the end gives you a plain-text report to paste into the support thread. It's free and open source.

Whatever method you use, the answer usually lands in one of three buckets, and each one is worth stating clearly:

What you found	What to write
Happens with only this plugin active	"Reproduces with only X active and Twenty Twenty-Five." The developer now owns it.
Only happens with one other plugin also active	"Only happens when X and Y are both active. Either one alone is fine." This is a conflict. Post it to both plugins' forums and link the threads.
Disappears with a default theme	"Goes away with Twenty Twenty-Five." Now it's a theme issue (or theme + plugin).

That middle row is the one people miss. Two plugins can each work fine alone and break only together, for example both loading a different version of the same JavaScript library, or both hooking the same filter at the same priority. If you only ever test "all on" vs. "one off," you will never see it.

5. The error log, trimmed

If there's a PHP error, it's the single most useful thing you can send. Turn on logging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the bug once, then open wp-content/debug.log. Post only the lines that appeared at the time of your test, usually a PHP Fatal error or Uncaught line plus the stack trace under it. Not the whole 4 MB file.

For front-end bugs (buttons that do nothing, endless spinners), open the browser console (F12 → Console) and the Network tab, reproduce, and copy any red errors. A failed admin-ajax.php or /wp-json/ request with its response body is gold.

Turn debug mode off again when you're done.

6. What you already tried

A short list saves a round trip:

Cleared site cache and CDN cache
Re-saved permalinks
Tested in a private window
Rolled the plugin back to 4.2.1 → works; 4.3.0 → broken

The last line is the best clue you can give a developer. It points straight at one release.

A template you can paste

**Expected:** 
**Actual:** (exact error text)

**Steps to reproduce:**
1.
2.
3.
Happens: every time / sometimes (x of y tries)
Who sees it: visitors / logged-in / admins / one browser

**Isolation:**
- With only [this plugin] (+ WooCommerce) and a default theme: yes / no
- Conflicts with: [other plugin + version], or "none found"

**Versions:** WP __ · PHP __ · plugin __ (last working __) · theme __
(Site Health info attached below)

**Errors:** (debug.log lines / console errors)

**Already tried:**
-

Why this works

Support teams triage. A thread with a clear expected/actual, clean steps, versions, and an isolation result can be reproduced in ten minutes, so it gets picked up first. A thread that says "broken, urgent" waits for a back-and-forth that can take days.

You're not doing their job for them. You're giving them the one thing only you have: your site.

If you maintain a plugin: consider pinning a version of this template in your support forum. The reports you get back will be better on day one.

Finding a broken WordPress plugin in 7 questions instead of 30 toggles

Alhiane Lahcen — Wed, 04 Nov 2026 12:24:35 +0000

Every WordPress support thread ends up at the same advice: "Deactivate all your plugins, then turn them back on one by one until it breaks."

It works. It is also slow, and on a live site it is risky. With 30 plugins you can be toggling for an hour while real visitors watch the site break and un-break. And there is one kind of bug it can miss completely.

This post covers a faster method you can do by hand, and the case that one-by-one testing gets wrong.

The problem with one-by-one

One-by-one testing is a linear search. With 30 plugins, the worst case is 30 rounds of "turn one on, reload, check."

Each round is not just a click. You reload the page, maybe clear a cache, maybe go through checkout again. Multiply that by 30.

Halve the suspects instead

Binary search is the same idea as the "guess my number" game. Every test should cut the list of suspects in half.

Write down your active plugins. Make a backup first.
Turn off half of them.
Check the problem.
- Problem gone? The culprit is in the half you turned off.
- Problem still there? The culprit is in the half that is still on.
Throw away the innocent half. Repeat with the suspects that are left.

With 30 plugins, the suspects go 30 → 15 → 8 → 4 → 2 → 1. That is about five tests instead of up to thirty.

A few practical tips:

Keep a written list. After the third round it is very easy to lose track of which plugins are "on" for which reason.
Test the same thing every time. Same page, same steps, same logged-in or logged-out state. If the bug only shows at checkout, go through checkout every round.
Clear caches between rounds. A page cache can show you the old result and send you down the wrong half.
Leave dependencies together. If an add-on needs its parent plugin (a WooCommerce extension needs WooCommerce), turn them off and on as a group.

The case one-by-one testing misses

Sometimes no single plugin is broken. Plugin A works alone. Plugin B works alone. Turn both on and checkout fails.

Look at what one-by-one testing does here. You turn everything off, then turn plugins back on one at a time. The site only breaks when the second plugin of the pair comes back. So you blame that plugin, report a bug to its author, and they cannot reproduce it, because it only fails next to the other one.

Plain binary search can trip on this too. Split the plugins in half and the pair may land on different sides. Then both halves work on their own, but the full set breaks. That result is the clue.

When you see "half A alone works, half B alone works, all together breaks," you know the culprit is a pair split across the two halves. To find it:

Keep half A fully on. Binary-search half B (turn half of B off, check, and so on). The plugin in B that brings the problem back is the first member of the pair.
Now keep that one plugin from B on. Binary-search half A the same way. That finds the second member.

It is still a handful of tests, and you end up with the real answer: "A and B conflict," not "B is broken."

Doing this on a live site

All of the above assumes you can switch plugins off. On a real store, every round means customers might see a broken checkout, missing features, or a broken layout.

The usual options:

A staging copy. The safest choice, if you have one and it really matches production (same PHP version, same plugin versions).
The Health Check & Troubleshooting plugin. Its troubleshooting mode disables plugins only for your session, so visitors keep the normal site. You still choose which plugins to enable yourself.
Recovery mode. For fatal errors, WordPress emails the admin a link to log in with the broken plugin paused.

I built a small open-source plugin, Culprit Finder, that runs the binary search above for you (disclosure: I'm the author). It switches plugins off only for your own logged-in browser, so visitors, search engines and other admins keep seeing the full site, and the active plugin list never changes. You answer "is the problem still there?" and it picks the next half. For a 30-plugin site that is usually around 7 answers, and it also catches two-plugin conflicts like the one above. When it is done, it gives you a plain-text report you can paste into a plugin's support forum.

It has exits in case something goes wrong: an Exit button, an emergency link that works even when you are logged out, and it stops by itself after 60 idle minutes (3 hours max). It is free, GPL, and makes no external requests. It cannot test your theme, must-use plugins, drop-ins, or server settings, so if the problem survives with every plugin off, look there next.

Summary

Don't toggle 30 plugins one at a time. Halve the suspects each round.
If both halves work alone but the full set breaks, you have a two-plugin conflict. Search one half while keeping the other on.
Report conflicts as pairs. "B breaks only when A is active" is a bug report a developer can act on.
On a live site, test in a way that does not change what visitors see.

What is the worst plugin conflict you have had to track down? I'm collecting real cases for the next post.

ValidatorKit: Simplify iOS Data Validation with Swift

Alhiane Lahcen — Wed, 25 Sep 2024 12:56:01 +0000

ValidatorKit: Simplify iOS Form Validation with Swift

Are you tired of writing repetitive, error-prone form validation code for your iOS apps? Meet ValidatorKit, a lightweight and flexible Swift package designed to streamline form validation in iOS development. Whether you're working with SwiftUI or UIKit, ValidatorKit offers a fluent API that makes defining and applying validation rules a breeze.

🚀 Key Features

Easy-to-use fluent API
Support for both SwiftUI and UIKit
Customizable validation rules
Lightweight with no external dependencies

📦 Installation

Add ValidatorKit to your project using Swift Package Manager:

dependencies: [
    .package(url: "https://github.com/Alhiane/ValidatorKit.git", from: "1.0.0")
]

🛠️ Usage Examples

Basic Validation: Single Field, Single Rule

import ValidatorKit

let schema = ValidationSchema()
    .field("email").required()
    .ready() // Always call .ready() to finalize the schema

let input = ["email": "user@example.com"]
let result = schema.validate(input)

if result.isValid {
    print("Email is valid!")
} else {
    print("Validation failed: \(result.errors["email"] ?? [])")
}

Multiple Rules for a Single Field

let schema = ValidationSchema()
    .field("password")
        .required()
        .min(8)
        .pattern("^(?=.*[A-Za-z])(?=.*\\d)[A-Za-z\\d]{8,}$")
    .ready()

let input = ["password": "pass123"]
let result = schema.validate(input)

if !result.isValid {
    print("Password errors: \(result.errors["password"] ?? [])")
}

Multiple Fields with Multiple Rules

let schema = ValidationSchema()
    .field("username").required().min(3)
    .field("email").required().email()
    .field("age").required().min(18)
    .ready()

let input = [
    "username": "jo",
    "email": "not-an-email",
    "age": 16
]

let result = schema.validate(input)

for (field, errors) in result.errors {
    print("\(field) errors: \(errors)")
}

Custom Validation Rules

let schema = ValidationSchema()
    .field("password").required().custom(message: "Password must be at least 8 characters") { value in
        guard let password = value as? String, password.count >= 8 else {
            return false
        }
        return true
    }
    .ready()

let input = ["password": "123abc4567"]
let result = schema.validate(input)

if !result.isValid {
    print("Password errors: \(result.errors["password"] ?? [])")
}

🖼️ SwiftUI Integration

Here's how you can use ValidatorKit in a SwiftUI form:

import SwiftUI
import ValidatorKit

struct RegistrationForm: View {
    @State private var username = ""
    @State private var email = ""
    @State private var password = ""
    @State private var validationErrors: [String: [String]] = [:]

    let schema = ValidationSchema()
        .field("username").required().min(3)
        .field("email").required().email()
        .field("password").required().min(8)
        .ready()

    var body: some View {
        Form {
            TextField("Username", text: $username)
            TextField("Email", text: $email)
            SecureField("Password", text: $password)

            Button("Register") {
                let result = schema.validate([
                    "username": username,
                    "email": email,
                    "password": password
                ])
                validationErrors = result.errors
                if result.isValid {
                    // Proceed with registration
                }
            }

            ForEach(validationErrors.keys.sorted(), id: \.self) { field in
                if let errors = validationErrors[field] {
                    Text(errors.joined(separator: ", "))
                        .foregroundColor(.red)
                }
            }
        }
    }
}

🧪 Testing Your Validation Logic

ValidatorKit makes it easy to test your validation schemas:

import XCTest
@testable import ValidatorKit

class ValidatorKitTests: XCTestCase {
    func testRegistrationFormValidation() {
        let schema = ValidationSchema()
            .field("username").required().min(3)
            .field("email").required().email()
            .field("password").required().min(8)
            .ready()

        // Test valid input
        let validInput = ["username": "john", "email": "john@example.com", "password": "password123"]
        let validResult = schema.validate(validInput)
        XCTAssertTrue(validResult.isValid)

        // Test invalid input
        let invalidInput = ["username": "jo", "email": "not-an-email", "password": "short"]
        let invalidResult = schema.validate(invalidInput)
        XCTAssertFalse(invalidResult.isValid)
        XCTAssertEqual(invalidResult.errors.count, 3)
    }
}

🎉 Conclusion

ValidatorKit offers a powerful, flexible, and easy-to-use solution for form validation in iOS applications. By providing a fluent API, support for custom rules, and seamless integration with both UIKit and SwiftUI, ValidatorKit simplifies one of the most common and often tedious aspects of iOS development.

Whether you're building a simple login form or a complex multi-step registration process, ValidatorKit can help you ensure data integrity and improve user experience with minimal effort. Its lightweight design and lack of external dependencies make it an excellent choice for projects of all sizes.

📚 Learn More

To dive deeper into ValidatorKit and explore its full potential, check out the GitHub repository.

For more iOS development insights and tutorials, visit my personal website at https://alhiane.com.

Happy coding! 🚀

Tell us how your story began in the world of programming?

Alhiane Lahcen — Mon, 08 Feb 2021 10:01:52 +0000

A young Moroccan, I got to know programming at the age of 16, and that was after I met someone and from there the story began

What about you?

Python makes me a poor programmer !!

Alhiane Lahcen — Mon, 14 Dec 2020 09:46:02 +0000

Python makes me a poor programmer !!
The best of the native programming languages, such as c ++ c and other languages, is that you are familiar with most of the functions scenarios in it and you are forced to demonstrate your strength in creating a logic that is closer to the production of mathematical principles, but # Python dispenses with all these things as it includes a huge library ready, no more efforts

#Python makes me a poor programmer
The best of the native programming languages, is that you are familiar with most of the functions scenarios in it and you are forced to demonstrate your strength in creating a logic that is closer to the production of mathematical principles ,
— Alhiane (@AlhianeLahcen) December 14, 2020

Laravel 8

Alhiane Lahcen — Thu, 10 Sep 2020 09:26:59 +0000

تم إصدار Laravel 8 الآن ويتضمن العديد من الميزات الجديدة بما في ذلك Laravel Jetstream , models directory, model factory classes, migration squashing, rate-limiting improvements, time testing helpers, ومكونات الشفرة الديناميكية ، والعديد من الميزات الأخرى.

قبل الانتقال إلى الميزات الجديدة ، نود الإشارة إلى أنه بدءًا من الإصدار 6 ، يتبع Laravel الآن semver وسيصدر إصدارًا رئيسيًا جديدًا كل ستة أشهر.

Read source article

لماذا لايهم أي Framework جافاسكريبت تختار ؟

Alhiane Lahcen — Tue, 04 Aug 2020 12:47:38 +0000

خلال مسيرتك البرمجية قد تسأل مرة على الأقل عن لماذا إخترت العمل بإطار معين بدل الآخر كإختيارك مثلا Vue , Angular , React , Svelte .

وإجابتك غالبا ماتكون أن الإطار سهل في بداية التعلم , أو انه متوافق مع تقنية أستعملها سابقا , وهنا قد يرميك الأخر بالتحيز فقط , أي أنك لم تكن مقتنعا به لولا أنه كان متوافقا مع تلك التقنية السابقة .

وهذا لايقتصر فقط على إطارات داخل جافاسكريبت بل معمم على جميع بيئات العمل , ولهذا كتبت المقال للحديث أكثر عن موضوع إختيارك لإطار عمل Javascript او للغة أخرى .

تتمة المقالة

error in winForm c# & sqlite

Alhiane Lahcen — Fri, 03 Jul 2020 12:14:50 +0000

Hi, everyone!
I just finished working on a project using SQLite & c# win Forms.
on mode developer, everything working well.
but when I'm creating setup to my project (using Advanced Installer) and after setup the app on client Machine
I got the error below

and there is my code in file app.config and folder structure

Promises vs Callbacks in Javascript

Alhiane Lahcen — Tue, 10 Mar 2020 11:24:41 +0000

If you are a professional Javascript programmer, you must have previously worked with the Callbacks function and in some cases, you are forced to use an answer function within an answer function within an answer function and so on (especially when dealing with Asynchronous commands such as AJAX operations and dealing with files and databases, etc. .. .) Until you get a relatively complex and hierarchical code as you will see in the following code:

function isUserTooYoung(id, callback) {
     openDatabase(function (db) { 
         getCollection(db, 'users', 
         function (col) { 
             find(col, { 'id': id }, 
             function (result) {
                  result.filter(function (user) { 
                      callback(user.age < 18) 
                    } 
                } 
            } 
        } 
    }

The isUserTooYoung function enables us to confirm that a particular user is an adult (over 18 years old), and for this, the connection is linked to the database, then the user searches to know his age and at last we confirm the age.

Use promises

Using promises, we will see that it gives us a clearer, simpler, and more semantic code. Every function that waits for an answer has a function that then picks up the answer from the function before it and passes it to the second function inside. With this concept, we can rewrite the previous code in a more elegant way as follows:


function isUserTooYoung(id) { 
        return openDatabase(db) 
        .then(getCollection) 
        .then(find.bind(null, {'id': id})) 
        .then(function(user) { 
            return user.age < 18; 
        }); 
    }

This is code in Node.js, but the idea and process are correct for other JavaScript applications.

Certainly, now the code has become clearer to you and easier to understand, as we can say that the openDatabase function promised the getCollection function to access certain data Datas after the successful connection to the database, and if we wanted to use the isUserTooYoung function in our program then it would be this way:


isUserTooYoung(id) 
 .then(function(result) {
   // Here you can deal with the end result
 }

Do not forget that there are other useful functions when using promises in JavaScript, such as the catch function, which is called when an operation or promises is not successful.

If you want to know more about JAVASCRIPT :

What should you do if you find a bug on a platform?

Alhiane Lahcen — Thu, 20 Feb 2020 20:40:56 +0000

There is no system in this world that is perfect, especially in the field of informatics. Any platform, application, site, program and others may not be that professional that you think.

You may also find that one day or sometimes you find a loophole or bug in one of the digital platforms that may be your golden opportunity to finally get your spoil, A non knowledge in how to act in this case may be removed Your spoil is about you, and we are here, my friend, to help you as best as possible.

First things first, why would you ever want to report them?

I remember a funny conversation that occurred between me and one of the people who may have found a problem in the Facebook platform that enables him to view the messages of other people without having to access their accounts, our friend design this between two options: to report the vulnerability, or to use it to read his girlfriend’s fake messages Doubts wandered around him.

From a simple point of view, if he would report the vulnerability and then Facebook thanked him for that and closed it is the worst scenario that might happen to him in this case, so he decided to use it to spy on his girlfriend for a period of not less than half a day before Facebook started to close it and suspend the name of one of People who reported it in her celebrity wall, or Hall Of Fame.

If in the future you encounter the same scenario, do not hesitate to report the vulnerability, why? Because any network, platform or system in this world (especially the famous ones) have what is called an award hunting system or Bounty Program This system allows you to report gaps in sites, applications, programs and platforms, then the vulnerability is evaluated according to its severity (is it A security vulnerability, a vulnerability, just a Bug ...) Then a cash prize is released that matches the rating given.

Platforms that pay you for the vulnerability:

In order to help you to know the most prominent platforms and companies that provide Bounty Program services or pay for finding gaps, there is a bugcrowd site that provides an alphabetical list of companies that pay you for a system of gaps that do not.

But before reporting your vulnerability make sure:

There is no problem, bug, or loophole that you can get a return from, my dear brother. You cannot, for example, sit alone and try to send a message on Facebook and Twitter, and you see an error of a strange type for the first time and you think that it is Bug and accelerate in the Facebook messaging. A few dollars, it doesn’t go like that.

*First, the vulnerability should be security, meaning that it is a vulnerability in some way that threatens the safety of the user or the safety of the work team, such as the holes that lead to logging into accounts, reading messages, or viewing personal information that another user is not supposed to see.

*The vulnerability must be tested more than once in more than one way

*That the defect or the loophole be in the system or the platform itself and not a platform listed in the middle, for example if you use a specific platform and then choose to register via Facebook and then you encounter problems or Bug, this will not be calculated because the problem is only in a third party and not the platform itself.

*Not to find bugs or bugs in the Alpha or Beta version of a specific platform

How to behave when you find a loophole that fits all of the above?

Using the Bugcrowd website and then going directly to the Bug Bounty Program page of the platform in which you discovered a gap, on the page you will find a group of emails and emails or Contact Forms that you can fill out directly in order to establish a connection between you and the site officials. Later, you will receive an answer from the site owners inquiring about some inquiries such as when the vulnerability occurred, how you discovered it, responsible tools and others, and they will ask you if you have a ready solution in advance of the vulnerability, they will accept all your answers and they will correct it or apply instructions that came from you to correct it, they will tell you Also at the price that this platform will pay for such information and a few days after correcting the vulnerability the way you want it will also add your name in the Hall of Fame for people who discovered holes in the platform.

What You Need To Do To Become A Great Developer?

Alhiane Lahcen — Sun, 16 Feb 2020 20:01:30 +0000

There are a ton junior developers learning to program for the first time. This is amazing since we always need more programmers, but it means that it is increasingly difficult to standout among the crowd of junior developers. In this video I will be sharing with you the steps that you can take in order to go from a good developer to a great developer and standout from the rest of the crowd. These are the exact steps and processes I took which made me standout far above the competition when applying for my first full time job.