amphibee / metaboxmaker

MetaboxMaker

MetaboxMaker is a powerful and flexible WordPress package designed to simplify the creation and management of custom metaboxes and fields. It provides developers with an object-oriented interface to generate various types of fields quickly and integrate them seamlessly into WordPress themes or plugins.

Features

• Object-Oriented Approach: Leverages modern PHP practices to offer a clean and maintainable codebase.
• Extensible Field Types: Includes a variety of field types such as text, number, file, image, video, and more.
• Customizable Options: Each field type comes with configurable settings to suit different requirements.
• Easy Integration: Easily integrates with existing WordPress setups, enhancing custom content types with minimal effort.
• Advanced Field Configurations: Supports advanced features like force deletion, custom upload directories, and unique filename callbacks.

Installation

To install MetaboxMaker, you can install the composer package into your WordPress plugin or theme directory.

composer require amphibee/metabox-maker

Usage

Basic Usage

Here is a quick example of how to create a custom metabox with text and number fields:

<?php

use AmphiBee\MetaboxMaker\Fields\Text;
use AmphiBee\MetaboxMaker\Fields\Number;

// Add fields to your metabox and display it in the post editor
Metabox::make('User Information', 'user_info')
       ->fields([
           Text::make('Username', 'username')
                ->placeholder('Enter your username'),
           Number::make('Age', 'age')
                ->min(18)
                ->max(100)
                ->step(1)
       ])
       ->context('side')
       ->priority('high');

// Full Example
use AmphiBee\MetaboxMaker\Fields\Group;
use AmphiBee\MetaboxMaker\Fields\Text;
use AmphiBee\MetaboxMaker\Metabox;
use AmphiBee\MetaboxMaker\Location;

Metabox::make('Test Fieldset', 'test_fieldset')
        ->fields([
            Text::make('Main Text', 'main_text')
                ->placeholder('Enter main text'),
            Group::make('Sub group', 'sub_group')
                ->fields([
                    Text::make('Sub Text', 'sub_text')
                        ->placeholder('Enter sub text'),
                ]),
        ])
        ->priority('high')
        ->context('side')
        ->location(Location::where('post_type', ['post', 'page']));

Advanced Features

You can also utilize advanced features such as image upload fields with custom settings:

<?php

use AmphiBee\MetaboxMaker\Fields\ImageUpload;

$imageField = ImageUpload::make('Profile Picture', 'profile_picture')
                ->maxFileSize('5mb')
                ->imageSize('medium')
                ->forceDelete(true);

Metabox::make('Profile', [$imageField])
       ->context('normal')
       ->priority('default');

Contributing

Contributions are welcome! Please feel free to submit pull requests or create issues for bugs and feature requests.

License

This project is licensed under the MIT License - see the LICENSE.md file for details.

metaboxmaker's Issues

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

composer

composer.json

• php ^8.1.0
• laravel/pint ^1.13
• pestphp/pest ^2.19
• rector/rector ^1.0.0
• nunomaduro/phpinsights ^2.8

---

• Check this box to trigger a request for Renovate to run again on this repository

Refactor Field Type Declaration from Property to Constant in Field Classes

Currently, the type of input field in our Field class hierarchy is managed as a protected property, which allows for dynamic modification of the field type at runtime. This is observed in the Text class as follows:

class Text extends Field
{
    /**
     * The type of input field. Defaults to 'text'.
     */
    protected string $type = 'text';
}

Additionally, there's functionality to modify this type through a setter method:

public function type(string|InputTextType $type): static
{
    $this->type = OptionValidation::check($type, InputTextType::class);
    return $this;
}

This design, while flexible, does not enforce type immutability which might be desirable for certain field types like text, url, or email.

Proposed Change

To ensure type safety and immutability, it is proposed to define the type of each field class using constants rather than properties. This would also involve the use of an interface to enforce the declaration of this constant in all field subclasses.

Step 1: Define an Interface

interface FieldType
{
    public const TYPE = '';
}

Step 2: Modify Existing Classes

Each field class, such as Text, Email, and URL, would implement the FieldType interface and define their own TYPE constant:

class Text extends Field implements FieldType
{
    public const TYPE = 'text';
}

class Email extends Field implements FieldType
{
    public const TYPE = 'email';
}

class URL extends Field implements FieldType
{
    public const TYPE = 'url';
}

Step 3: Remove Setter Method

Since the field type will now be immutable and defined at compile-time, the setter method type() would be removed from these classes.

Impact

This change will:

• Enhance the type safety of the field classes.
• Ensure the immutability of field types, aligning with best practices for constant usage.
• Simplify the class design by removing unnecessary runtime type checks and modifications.

This approach does, however, reduce the flexibility of changing the field type dynamically but increases reliability and predictability of field behavior across our application.

Extend addField handling in FieldTransformer to support non-field instances like Heading and Divider

In the src/Transformer/FieldTransformer.php file, the current implementation only checks for instances of Field to process through the addField method. This implementation is restrictive as there are other types of objects that need processing, such as Heading and Divider, which are not strictly fields but still require similar handling.

Issue

The code snippet:

if ($subField instanceof Field) {
    $this->addField($subField);
}

This condition only allows objects of type Field to be processed. However, instances of Heading or Divider are also valid inputs that need to be added but are currently being excluded.

Suggested Fix

We propose extending the condition to include Heading and Divider types. This can be implemented by modifying the existing conditional check to include these types, or by implementing a new interface that these classes can inherit, representing all types that are valid for addField.

A possible modification might look like this:

if ($subField instanceof Field || $subField instanceof Heading || $subField instanceof Divider) {
    $this->addField($subField);
}

Alternatively, defining a new interface like FieldCompatible could make the system more flexible and maintainable:

interface FieldCompatible {}

class Field implements FieldCompatible {}
class Heading implements FieldCompatible {}
class Divider implements FieldCompatible {}

if ($subField instanceof FieldCompatible) {
    $this->addField($subField);
}