DEV Community: Gerardo Andrés Ruiz Castillo

Enhancing UI Reactivity: Dynamic Editor Panels with Alpine.js and PHP

Gerardo Andrés Ruiz Castillo — Mon, 18 May 2026 22:01:03 +0000

Building highly interactive user interfaces often means juggling complex client-side state and ensuring seamless communication with the backend. For the Breniapp/brenia project, we recently tackled this by revamping the editor panel to offer a more fluid user experience, specifically focusing on dynamic layer expansion and real-time canvas preview updates. This overhaul leveraged Alpine.js for frontend reactivity, streamlining how users interact with generated content.

The Challenge: Static Panels vs. Dynamic Needs

Previously, parts of our editor panel might have relied on full page reloads or more cumbersome JavaScript to manage UI state. As features like iterative content generation and customizable layers became more central, the need for an instant, reactive UI grew. Users expect immediate visual feedback and the ability to expand and collapse detailed controls without disruption.

Alpine.js for Lightweight Reactivity

The core of this enhancement lies in Alpine.js, a lightweight JavaScript framework that brings the power of reactive data binding directly to your HTML markup. We introduced x-data to manage the state of the editor panel, specifically for expandedLayer (controlling the visibility of layer details) and canvasImageUrl (displaying the generated content preview). This declarative approach simplifies complex UI logic.

Event-Driven Updates: Seamless Canvas Previews

A critical aspect was updating the canvas preview in real-time as content is generated. Rather than polling or manual DOM manipulation, we implemented an event-driven mechanism. After a generation process completes, a generation-completed event is dispatched on the client-side. Alpine.js then listens for this event and updates the canvasImageUrl state, instantly refreshing the preview without user intervention.

This approach cleanly separates the backend generation logic from the frontend rendering, making the system more robust and easier to maintain. The PHP backend is responsible for processing the generation request and ultimately providing the new image URL, which is then picked up by the Alpine.js component.

Consider a simplified PHP endpoint that might handle the image generation request and provide the updated URL:

<?php

namespace App\Controllers;

use App\Services\ImageGenerator;
use Framework\Http\Response;

class EditorApiController
{
    private ImageGenerator $generator;

    public function __construct(ImageGenerator $generator)
    {
        $this->generator = $generator;
    }

    public function generateCanvasPreview(): Response
    {
        // Assume request body contains necessary generation parameters
        $params = json_decode(file_get_contents('php://input'), true);

        // Call a service to process and generate the image
        $newImageUrl = $this->generator->createImage($params);

        // Return the new URL to the client
        return new Response(json_encode([
            'imageUrl' => $newImageUrl,
            'message' => 'Generation complete!'
        ]), 200, ['Content-Type' => 'application/json']);
    }
}

This PHP code snippet illustrates a backend endpoint that would receive a request, trigger the image generation process (e.g., in a ImageGenerator service), and then return a JSON response containing the imageUrl. On the frontend, an Alpine.js component would make an AJAX call to this endpoint, and upon receiving the imageUrl, dispatch a custom generation-completed event (or directly update its state if the AJAX call is handled within the component).

Conclusion and Actionable Takeaway

The shift to a more reactive editor panel using Alpine.js significantly enhanced the user experience within Breniapp/brenia. By leveraging x-data for local component state and event listeners for inter-component communication, we achieved dynamic UI behavior with minimal JavaScript overhead. If you're looking to add interactive elements and real-time feedback to your web applications without the complexity of a full-blown framework, consider Alpine.js. Pair it with a robust PHP backend for data processing, and you can build highly responsive interfaces that delight users.

Actionable Takeaway: When faced with static UI elements that need to become dynamic, explore lightweight JavaScript frameworks like Alpine.js for managing frontend state and implementing event-driven updates. Design your backend APIs to provide the necessary data payloads for these frontend interactions.

Manejo de Errores y Prevención de Publicaciones Duplicadas en devlog-ist/landing

Gerardo Andrés Ruiz Castillo — Wed, 11 Mar 2026 07:04:04 +0000

Introducción

En el proyecto devlog-ist/landing, que permite a los usuarios publicar contenido en diversas plataformas, se ha trabajado en mejorar la robustez del sistema y prevenir problemas comunes relacionados con la publicación de contenido.

El Desafío

El sistema presentaba dos problemas principales:

Errores 500 al alcanzar el límite diario de publicaciones: Cuando un usuario intentaba publicar más contenido del permitido en un día, el sistema respondía con un error 500 genérico, lo cual no era informativo ni amigable.
Publicaciones duplicadas: En ciertas ocasiones, el sistema programaba publicaciones y, al mismo tiempo, el usuario intentaba publicar el mismo contenido de forma inmediata, resultando en una doble publicación.

La Solución

Para abordar estos problemas, se implementaron las siguientes soluciones:

Manejo de DailyPostLimitReachedException: Se capturó la excepción DailyPostLimitReachedException en todas las acciones de publicación (LinkedIn, Dev.to, individual y masiva). En lugar de mostrar un error 500, se muestra una notificación traducida al idioma del usuario, indicando que ha alcanzado su límite diario de publicaciones.
```
try {
    // Lógica de publicación
} catch (DailyPostLimitReachedException $e) {
    // Mostrar notificación traducida
    echo __('daily_publish_limit_reached');
}
```
Cancelación de publicaciones programadas pendientes: Al publicar contenido de forma inmediata, se cancelan los registros de ScheduledPost pendientes para evitar la doble publicación desde la cola de programación.
```
// Cancelar publicaciones programadas pendientes
ScheduledPost::where('post_id', $postId)->delete();
```

Decisiones Clave

Traducciones: Se agregaron traducciones para el mensaje daily_publish_limit_reached en los cuatro idiomas soportados (inglés, español, francés y alemán).
Robustez: Manejar la excepción específica mejora la experiencia del usuario al proporcionar información clara sobre el problema.
Prevención: Cancelar las publicaciones programadas evita la duplicación de contenido, manteniendo la integridad del sistema.

Resultados

Se eliminaron los errores 500 relacionados con el límite diario de publicaciones, mejorando la experiencia del usuario.
Se previnieron las publicaciones duplicadas, asegurando que el contenido se publique solo una vez.

Lecciones Aprendidas

Es crucial manejar las excepciones específicas en lugar de depender de errores genéricos. Además, la prevención de problemas a través de la cancelación de tareas redundantes puede mejorar significativamente la fiabilidad del sistema.

Optimizing Deployments for Low-Resource VPS Environments

Gerardo Andrés Ruiz Castillo — Sat, 07 Mar 2026 07:31:05 +0000

Deploying applications to low-resource Virtual Private Servers (VPS) can be challenging. This post explores strategies for optimizing deployments to minimize resource consumption and improve reliability, specifically for the devlog-ist/landing project.

The Challenge

Low-resource VPS environments often suffer from limited RAM and CPU. Standard deployment procedures can easily exhaust these resources, leading to slow deployments, failed builds, and application instability. The goal is to reduce the memory footprint and optimize build processes to fit within the constraints of the VPS.

Strategies for Optimization

Several techniques can be employed to optimize deployments for low-resource environments:

Reusing node_modules: Similar to the vendor/ directory in PHP projects, the node_modules/ directory can be reused from the previous release. This avoids re-downloading and re-installing dependencies on every deploy, saving significant time and bandwidth. The principle here is that dependencies change less frequently than the application code itself.
Limiting Node RAM Usage: Node.js can consume substantial RAM during builds. By setting the NODE_OPTIONS=--max-old-space-size=512 environment variable, we can limit the maximum memory Node.js can use. This prevents the build process from exhausting all available RAM and triggering out-of-memory errors.
Utilizing npm ci --prefer-offline: The npm ci command performs a clean install from the package-lock.json file, ensuring consistent dependency versions. The --prefer-offline flag instructs npm to use the local cache whenever possible, further reducing network activity and improving speed.
Splitting Deployments into Phases: Separating the deployment process into pre-activate and post-activate phases allows for more granular control and error handling. Pre-activate tasks can include copying necessary files and running database migrations, while post-activate tasks can involve clearing caches and restarting services.
Timing Deployment Phases: Adding timing information to each deployment phase (e.g., using time command) helps identify bottlenecks and areas for further optimization. This allows for data-driven decisions when making changes to the deployment process.

Implementation

The following example demonstrates how to limit Node RAM usage in a deployment script:

NODE_OPTIONS=--max-old-space-size=512 npm ci --prefer-offline

This command sets the NODE_OPTIONS environment variable to limit the maximum old space size to 512MB before running npm ci. This prevents the Node.js process from consuming excessive memory during installation.

Conclusion

Optimizing deployments for low-resource VPS environments requires careful consideration of resource consumption and build processes. By reusing node_modules, limiting Node RAM usage, utilizing npm ci --prefer-offline, splitting deployments into phases, and timing deployment steps, we can significantly improve the reliability and speed of deployments, even on constrained hardware.

Tenant-Specific Scheduling in devlog-ist/landing

Gerardo Andrés Ruiz Castillo — Sat, 07 Mar 2026 06:00:05 +0000

Introduction

In the devlog-ist/landing project, which likely involves a landing page generator with publishing capabilities, a key requirement is the ability to tailor content scheduling to individual tenants. This post explores how configurable publishing schedules were introduced to provide a more natural and less bot-like content delivery experience, enhancing the platform's flexibility and user experience.

The Challenge: Hardcoded Scheduling

Previously, the post scheduling mechanism relied on hardcoded values within the PostStaggeringService. This approach lacked the flexibility needed to accommodate the diverse needs of different tenants. All tenants were subject to the same rigid schedule, leading to potentially unnatural publishing patterns and a one-size-fits-all experience.

The Solution: Configurable Tenant Settings

The solution involved introducing configurable publishing schedule settings for each tenant. Specifically, tenants can now adjust the following parameters via the AutomationSettings page:

Publish Window Hours (Start/End): Define the time frame during which posts should be published.
Maximum Posts Per Hour: Control the density of posts published within the defined window.
Jitter Minutes: Introduce randomness to the exact publishing time, making the schedule less predictable and more organic.

Implementation Details

The hardcoded values in PostStaggeringService were replaced with these tenant-specific settings. This allows each tenant to customize their publishing schedule according to their preferences and audience behavior. For example, consider a hypothetical scenario where a tenant wants to publish content primarily during business hours, with a limited number of posts per hour and a slight variation in timing to avoid appearing robotic. The configuration might look like this:

$tenantSettings = [
    'publish_start_hour' => 9,
    'publish_end_hour' => 17,
    'max_posts_per_hour' => 3,
    'jitter_minutes' => 10,
];

// The PostStaggeringService would then use these settings to determine the
// appropriate time to publish each post.

Benefits of Configurable Scheduling

Improved User Experience: Tenants can tailor content delivery to their specific audience, leading to higher engagement.
More Natural Publishing Patterns: The introduction of jitter and customizable windows prevents the appearance of automated bot-like behavior.
Increased Flexibility: The platform becomes more adaptable to the diverse needs of different tenants.

Conclusion

By introducing configurable publishing schedules, the devlog-ist/landing project has significantly enhanced its content delivery capabilities. This change provides tenants with the flexibility they need to create a more engaging and natural user experience, moving away from rigid, hardcoded schedules towards a more dynamic and personalized approach.

Enhancing Security Audits: Avoiding False Positives in File Path Detection

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 12:33:04 +0000

Introduction

In the devlog-ist/landing project, we're continually working to improve our security posture. A recent focus has been on refining our security auditing tools to reduce false positives, particularly around the detection of potentially sensitive file paths.

The Challenge

Our automated security audits sometimes flagged placeholder file paths as potential exposures of sensitive information. For example, paths like /path/to/certificate or /path/to/private/key were incorrectly identified as containing actual private keys or certificates. This was due to the LLM misinterpreting these paths, which were intended only as examples, as real file locations containing sensitive data.

The Solution

To address this, we've reinforced the rule that paths matching the /path/to/ pattern are always examples. This helps the LLM to correctly interpret these paths and avoid flagging them as potential security risks. Here's an example of how we might handle this in code:

<?php

class SecurityAudit
{
    public function isSensitivePath(string $path): bool
    {
        // Check if the path matches the /path/to/ pattern and exclude it from sensitive checks
        if (preg_match('/^\/path\/to\//', $path)) {
            return false; // It's an example path, not a real one
        }

        // Perform other checks for sensitive files (e.g., checking for known certificate extensions)
        if (strpos($path, '.pem') !== false || strpos($path, '.key') !== false) {
            return true; // Potentially sensitive file
        }

        return false;
    }
}

This code snippet demonstrates how we can use a regular expression to identify placeholder paths and exclude them from further security checks. By explicitly excluding paths that match the /path/to/ pattern, we prevent false positives and ensure that our security audits focus on real potential vulnerabilities.

Key Decisions

Regular Expression Matching: Using preg_match to identify example paths based on the /path/to/ pattern.
Exclusion Logic: Implementing logic to exclude identified example paths from sensitive file checks.

Results

By implementing this change, we've significantly reduced the number of false positives in our security audits. This allows our security team to focus on real potential vulnerabilities, improving our overall security posture.

Lessons Learned

This experience highlights the importance of context in security auditing. Automated tools must be able to distinguish between example paths and real file locations to avoid generating unnecessary alerts. By carefully crafting our audit rules and incorporating contextual awareness, we can improve the accuracy and effectiveness of our security audits.

Tenant Landing Page Optimization: Caching for Performance

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 10:55:03 +0000

The devlog-ist/landing project delivers landing pages for tenants. A recent optimization focused on reducing database load by implementing a caching strategy for tenant-specific landing page data. This change significantly improves performance by minimizing redundant database queries.

The Problem

Previously, each request to a tenant's landing page triggered multiple database queries to fetch stats, badges, recommendations, and post languages. In particular, loading all posts to generate statistics resulted in a substantial performance bottleneck. This "load ALL posts for stats" query ran on every landing page hit, even if the data hadn't changed. This approach was clearly unsustainable as the number of tenants and posts grew.

The Solution: Caching Tenant Landing Page Data

To address this, a caching mechanism was introduced. Now, tenant-specific landing page data is cached with a Time-To-Live (TTL) of one hour. This means that the first request for a tenant's landing page will still incur the database queries, but subsequent requests within the hour will be served from the cache. The cache is automatically invalidated whenever a post is saved or deleted, ensuring data consistency.

Here's a simplified example of how the caching might be implemented in PHP:

<?php

use Symfony\Component\Cache\Adapter\FilesystemAdapter;

$cache = new FilesystemAdapter();
$cacheKey = 'tenant_' . $tenantId . '_landing_page_data';

$landingPageData = $cache->get($cacheKey, function () use ($tenantId) {
    // Fetch data from the database
    $stats = getTenantStatsFromDatabase($tenantId);
    $badges = getTenantBadgesFromDatabase($tenantId);
    $recommendations = getTenantRecommendationsFromDatabase($tenantId);
    $postLanguages = getTenantPostLanguagesFromDatabase($tenantId);

    $data = [
        'stats' => $stats,
        'badges' => $badges,
        'recommendations' => $recommendations,
        'postLanguages' => $postLanguages,
    ];

    return $data;
});

// Use $landingPageData to render the landing page

This code snippet demonstrates how the Symfony cache component can be used to store and retrieve tenant landing page data. The get method either returns the cached data or executes the provided closure to fetch fresh data from the database if the cache is empty or expired.

The Impact

This caching strategy significantly reduces the number of database queries per request, particularly on cache warm. More importantly, it eliminates the expensive "load ALL posts for stats" query that previously ran on every landing page hit. This leads to improved landing page load times and reduced database load, resulting in a better user experience and improved system scalability.

Geolocation Optimization: Caching and Local Database Lookup

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 10:43:05 +0000

This post discusses optimizing geolocation lookups in the devlog-ist/landing project, which enhances user experience by personalizing content based on location.

The Challenge

Initially, the application relied on an external HTTP service (ip-api.com) to determine a visitor's country based on their IP address. This approach introduced significant latency, adding approximately 1 second to each page load. Furthermore, relying on an external service meant potential rate limits and service disruptions.

The Solution

To address these issues, we implemented two key optimizations:

Local Database Lookup: Replaced the external HTTP calls with lookups against a local MaxMind GeoLite2-City database. This eliminates network latency and reliance on an external service.
Caching: Introduced a caching layer to minimize repeat lookups. Resolved country codes are cached for 7 days, while unresolvable IPs are cached for 1 hour.

Implementation Details

The local database lookup is performed using the maxminddb package in Go. Here's an example:

package main

import (
    "fmt"
    "net"

    "github.com/oschwald/geoip2/maxminddb"
)

func main() {
    db, err := maxminddb.Open("GeoLite2-City.mmdb")
    if err != nil {
        panic(err)
    }
    defer db.Close()

    ip := net.ParseIP("8.8.8.8")

    var record struct {
        Country struct {
            IsoCode string `json:"iso_code"`
        } `json:"country"`
    }


    err = db.Lookup(ip, &record)
    if err != nil {
        panic(err)
    }
    fmt.Printf("Country code: %v\n", record.Country.IsoCode)
}

This code snippet demonstrates how to open the MaxMind database, perform a lookup for a given IP address, and extract the country code. A similar function integrates with a caching layer (e.g., Redis) to store the results. When an IP address needs to be geolocated, the cache is checked first; if the result is not in the cache, the local database lookup is performed, and the result is then stored in the cache with the appropriate expiration time.

To simplify the process of keeping the GeoLite2-City database up-to-date, an artisan command was added to download the latest version.

The Result

By switching to a local database and implementing caching, we significantly reduced the latency associated with geolocation lookups. This resulted in faster page load times and an improved user experience. The application is also more resilient to external service outages and rate limits.

The Takeaway

Optimizing geolocation lookups can have a significant impact on application performance and reliability. By leveraging local databases and caching, developers can minimize latency and improve the user experience. Regularly updating the local database is crucial to ensure accuracy.

Optimizing Tenant Schema Access in Go Applications

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 06:01:04 +0000

Introduction

In multi-tenant applications, efficient management of database schemas is crucial for performance. This post explores how caching and schema tracking can significantly reduce database load in Go applications.

The Challenge

Accessing tenant-specific data often involves repetitive database queries to check for schema existence and set the appropriate search path. These redundant operations can lead to performance bottlenecks, especially when dealing with a large number of tenants. Specifically, the devlog-ist/landing project experienced a high volume of pg_class queries and redundant SET search_path statements, impacting overall application responsiveness.

The Solution

To address these performance issues, the following optimizations were implemented:

Caching Tenant Table Existence: The result of the tenantsTableExists() check is now cached using a persistent cache with a Time-To-Live (TTL) of one hour. This eliminates a significant number of pg_class queries.
Tracking Applied Schema: The application now tracks the currently applied schema. Before executing a SET search_path statement, it checks if the desired tenant schema is already set. If so, the redundant statement is skipped.
Skipping Redundant Schema Reset: Similarly, the resetTenantSchema() function is skipped when the schema is already null, avoiding unnecessary database interactions.

These optimizations are implemented in Go, leveraging caching mechanisms and state management to minimize database load. Here's an example illustrating the concept of caching the schema existence:

package main

import (
    "fmt"
    "time"
)

var schemaCache = make(map[string]bool)
var cacheTTL = time.Hour

func checkSchemaExists(schemaName string) bool {
    // Check if the schema exists in the cache
    if exists, ok := schemaCache[schemaName]; ok {
        fmt.Println("Schema existence retrieved from cache for:", schemaName)
        return exists
    }

    // Simulate a database call to check schema existence
    fmt.Println("Checking schema existence in database for:", schemaName)
    // In real implementation, this would be a database query
    exists := simulateDatabaseCheck(schemaName)

    // Store the result in the cache with a TTL
     schemaCache[schemaName] = exists

    // Invalidate cache after TTL
    go func() {
         time.Sleep(cacheTTL)
         delete(schemaCache, schemaName)
         fmt.Println("Cache invalidated for:", schemaName)
    }()

    return exists
}

func simulateDatabaseCheck(schemaName string) bool {
    // Replace with actual database query
    // For example:
    // err := db.QueryRow("SELECT 1 FROM pg_namespace WHERE nspname = $1", schemaName).Scan(nil)
    // return err == nil
    return true // Simulating schema exists
}

func main() {
     schemaName := "tenant_123"
     exists := checkSchemaExists(schemaName)
     fmt.Println("Schema exists:", exists)

    // Subsequent check will use the cache
     exists = checkSchemaExists(schemaName)
     fmt.Println("Schema exists:", exists)

     time.Sleep(2 * time.Second) // Give some time for goroutine to execute


}

Results

These optimizations resulted in a significant reduction in database queries:

Approximately 13,000 pg_class queries per day were eliminated.
Around 10,000 redundant SET search_path statements per day were skipped.

This leads to improved application performance and reduced load on the database server.

Lessons Learned

Caching and state management are powerful tools for optimizing database-intensive applications. By identifying and eliminating redundant database operations, developers can achieve significant performance gains. Regular monitoring and profiling of database queries can help identify areas for optimization.

Refactoring for Readability: Moving Sections in devlog-ist/landing

Gerardo Andrés Ruiz Castillo — Thu, 05 Mar 2026 12:29:06 +0000

When working on a project like devlog-ist/landing, which likely involves presenting information in a clear and user-friendly way, the layout of different sections becomes crucial.

The Importance of Layout

Effective layout enhances readability and user experience. Content should be organized logically and presented in a way that's easy to digest. Sometimes, initial design decisions need revisiting as the project evolves and more information is available about user behavior or content priorities.

Moving Sections for Better Space Utilization

The recent commit focused on improving the stats page by relocating key sections. The 'Technologies', 'Experience', and 'Education' sections were moved from a narrow left sidebar to the main column. This change was implemented across the simple and default themes to utilize the available horizontal space more efficiently. A minor layout tweak was also applied to the nan theme.

Before:

+---------------------+-----------------------+
| Technologies        | Contribution Activity |
| Experience          |                       |
| Education           |                       |
+---------------------+-----------------------+

After:

+-----------------------+
| Contribution Activity |
+-----------------------+
| Technologies          |
| Experience            |
| Education             |
+-----------------------+

Benefits of the Change

Moving these sections to the main column offers several advantages:

Improved Readability: Wider columns generally allow for more comfortable reading.
Better Space Utilization: The main column provides more horizontal space, allowing the content to breathe.
Enhanced User Experience: A more balanced layout can lead to a more engaging and intuitive user experience.

Actionable Takeaways

When designing or refactoring layouts, consider how different sections interact with each other and how they utilize the available space. Don't hesitate to revisit initial design decisions as the project evolves and new information becomes available.

Refining the Retro Theme: Enhancing the Profile Bio

Gerardo Andrés Ruiz Castillo — Thu, 05 Mar 2026 09:52:03 +0000

The devlog-ist/landing project focuses on creating an engaging landing page experience. A recent update refines the retro theme by adjusting the profile bio's display. This post will explain the adjustments made to enhance the bio section within the retro theme.

The Initial Constraint

Previously, the profile bio section in the retro theme had a max-w-lg CSS class applied. This limited the maximum width of the bio content, potentially causing text to wrap prematurely on larger screens and not fully utilizing available space.

Removing the Constraint

The update involved removing the max-w-lg constraint. This allows the profile bio to expand and fill the available horizontal space more effectively, leading to a cleaner and more readable presentation, especially on wider displays.

Impact

Removing this constraint ensures that the profile bio adapts fluidly to different screen sizes, improving the overall user experience by optimizing readability and visual appeal. This small change contributes significantly to the polished look and feel of the retro theme.

Next Steps

Consider testing the landing page on various screen sizes to ensure the profile bio scales appropriately and remains visually appealing across different devices.

Enhancing devlog-ist/landing: Sidebar Technologies and Expert Labels

Gerardo Andrés Ruiz Castillo — Thu, 05 Mar 2026 09:39:05 +0000

Introduction

Enhancements have been made to the devlog-ist/landing project, a platform designed for developers. These updates focus on improving the presentation and accessibility of technologies and expertise showcased on the landing pages.

Technologies Sidebar

The 'Technologies' section has been relocated to the left sidebar in both the 'default' and 'simple' themes. This adjustment aims to provide a more consistent and accessible layout, ensuring that key technologies are prominently displayed and easily navigable.

Expert Labeling

A significant update involves the introduction of an "Expert in:" label across all eight themes. This label is strategically placed before the expert tech tags, providing clear indication of a user's proficiency in a particular technology. The colored tags previously used in 'nan' themes have been removed to maintain visual consistency across all themes.

Example of how the label could be implemented in Go:

package main

import "fmt"

func main() {
    tech := "Go"
    fmt.Printf("Expert in: %s\n", tech)
}

Translation Key Addition

To ensure comprehensive support, the expert_in translation key has been added across all four supported languages. This addition facilitates proper localization of the "Expert in:" label, catering to a global audience.

Impact and Benefits

These changes collectively contribute to a more refined and user-friendly experience within the devlog-ist/landing platform. By relocating the Technologies section and clearly labeling expert proficiencies, users can more effectively highlight their skills and expertise.

Enhancing Tenant Management in devlog-ist/landing with Plan Visibility

Gerardo Andrés Ruiz Castillo — Thu, 05 Mar 2026 09:10:05 +0000

This post details the addition of a 'plan' column to the admin tenants table in the devlog-ist/landing project, improving tenant management and visibility.

The Need for Plan Visibility

The original tenant management interface lacked a clear, immediate indicator of each tenant's current plan. This required administrators to navigate to separate sections or run custom queries to determine the plan associated with each tenant, creating unnecessary overhead.

Implementation: Adding the 'Plan' Column

The solution involved modifying the admin tenants table to include a 'plan' column. This column displays each tenant's current plan using a colored badge, mirroring the style already in use within the users table. This ensures visual consistency and ease of recognition.

To implement this, the table rendering logic was updated to fetch the plan information for each tenant. A mapping was created between plan types and corresponding badge colors. This mapping is used to dynamically generate the appropriate badge style for each tenant's plan.

Example of badge generation:

function getPlanBadge(string $plan):
string {
    $colorMap = [
        'basic' => 'gray',
        'premium' => 'green',
        'enterprise' => 'purple',
    ];
    $color = $colorMap[$plan] ?? 'blue';
    return "<span class='badge text-bg-{$color}'>{$plan}</span>";
}

This function takes a plan name as input and returns an HTML span element representing a colored badge. The color is determined by a predefined $colorMap. If the plan is not found in the map, a default color ('blue') is used.

Benefits and Impact

Adding the 'plan' column provides several key benefits:

Improved Visibility: Administrators can now see each tenant's plan at a glance, without needing to navigate to other sections.
Enhanced Efficiency: Streamlines tenant management workflows, reducing the time required to identify and manage tenants based on their plans.
Consistent UI: Maintains a consistent user interface by using the same badge style as the users table.

Conclusion

By adding a 'plan' column with colored badges to the admin tenants table, the devlog-ist/landing project has significantly improved the usability and efficiency of its tenant management interface. This simple addition provides immediate value by increasing visibility and reducing administrative overhead.