amphibee / pollen-framework Goto Github PK

Implement a wrapper class that allows for the fluent declaration of post types and taxonomies. The goal is to provide a more intuitive and convenient way to define arguments for post types and taxonomies using the Extended CPT library.

Tasks:

1. Create a new wrapper class, let’s name it “PostType”, that will serve as a fluent interface for declaring post types and taxonomies.
2. Implement methods in the “PostType” and “Taxonomy” class that correspond to each argument supported by the Extended CPT library.
3. Ensure that each method sets the corresponding argument value when invoked.
4. Integrate the “PostType” and “Taxonomy” class with the existing codebase, replacing manual declaration of post types and taxonomies with the fluent syntax.
5. Update the documentation to include information about the new fluent wrapper class and its usage.

Example Usage:
To declare a post type “book” with the argument “show_in_feed” set to true, the code can be written as follows:

PostType::make('book')->showInFeed();

Expected Outcome:
After completing this ticket, developers will be able to declare post types and taxonomies using a fluent syntax, simplifying the process and enhancing code readability. The new wrapper class will provide a convenient way to set arguments for post types and taxonomies, aligning with the principles of the Extended CPT library.

This ticket involves creating an Artisan command that generates Hookable classes, designed to invoke WordPress actions or filters. These generated classes will be placed in the “App/Hooks” directory, streamlining the process of creating classes for handling WordPress hooks.

Tasks:

1. Develop a new Artisan command named “make:hook” that accepts a class name as an argument. For instance, running php artisan make:hook MyHook should generate a Hookable class named “MyHook.”
2. Design the command logic to generate the Hookable class file within the “App/Hooks” directory, following the specified code structure.
3. Integrate necessary placeholders in the generated class file, such as the class name and comments.
4. Implement validation checks to ensure that the class name adheres to proper naming conventions and does not conflict with existing classes.
5. Test the “make:hook” command by generating a sample Hookable class and verifying its presence and contents in the “App/Hooks” directory.
6. Update the documentation to provide clear instructions on how to use the “make:hook” command and generate Hookable classes for WordPress actions and filters.

Expected Outcome:
Upon completing this ticket, the framework will include a new Artisan command, “make:hook,” which streamlines the process of creating Hookable classes for WordPress actions and filters. Developers will be able to generate these classes with ease, enabling them to define custom behavior for WordPress hooks efficiently. The generated classes will adhere to the specified code structure and will be placed in the “App/Hooks” directory.

Implement Gutenberg’s theme.json file within the resources/views directory, exploring the possibility of specifying a custom location outside the traditional WordPress theme.

Tasks:

1. Create a new directory, “resources/views,” within the project structure.
2. Move the theme.json file to the newly created “resources/views” directory.
3. Update the necessary configurations or code references to point to the new location of the theme.json file.
4. Test the implementation to ensure the theme.json file is recognized and applied correctly by Gutenberg.
5. Document the changes made and update the documentation accordingly to reflect the new location of the theme.json file.

Expected Outcome:
Upon completion of this ticket, the theme.json file will be relocated to the “resources/views” directory. The implementation aims to verify whether Gutenberg can recognize and utilize the theme.json file from a custom location outside the traditional WordPress theme structure. This provides an opportunity to organize the theme-related files in a different directory while still leveraging Gutenberg’s configuration capabilities.

This ticket involves implementing an abstraction for a “Hookable” class, inspired by the implementation provided by the Themosis framework. The “Hookable” class allows for the delayed execution of specific code within the “register” method, triggered by a designated WordPress action hook.

Tasks:

1. Create a new class, let’s name it “Hookable,” that extends the base functionality from the Themosis framework’s implementation.
2. Define a public property, “$hook,” within the “Hookable” class, which represents the WordPress action hook to trigger the execution of the “register” method.
3. Implement the “register” method within the “Hookable” class, containing the code that should be executed when the designated WordPress action hook is triggered.
4. Add support for defining an execution priority by introducing a public property, “$priority,” within the “Hookable” class. This property allows for setting the priority level at which the “register” method should be executed.
5. Integrate the “Hookable” class into the application’s root, ensuring it serves as an entry point for accessing and utilizing WordPress APIs.
6. Update the documentation to include information about the newly implemented “Hookable” class and its usage within the application.

Expected Outcome:
Once this ticket is completed, we will have an abstraction for the “Hookable” class, similar to the implementation provided by the Themosis framework. This abstraction will enable delayed execution of code within the “register” method, triggered by a specific WordPress action hook. Developers will be able to utilize the “Hookable” class to efficiently extend WordPress functionality and customize behavior based on specific action hooks.

Complete the implementation of WP-CLI (WordPress Command-Line Interface) to enable database operations that require an active connection. Currently, the implementation is partial, and certain commands, such as “wp search-replace,” do not function as expected due to the lack of an active database connection.

Tasks:

1. Review the existing WP-CLI implementation and identify the commands that require an active database connection.
2. Modify the affected commands to establish a connection with the database before executing the desired operations.
3. Test the modified commands to ensure they function correctly, allowing operations like search and replace to be performed with an active database connection.
4. Handle potential errors or exceptions that may occur during the database operations and provide appropriate error messages or guidance.
5. Update the documentation to reflect the changes and provide usage instructions for the modified commands.

Expected Outcome:
Once this ticket is completed, WP-CLI will have a fully functional implementation for database operations. Users will be able to execute commands like “wp search-replace” with an active connection to the database, enabling them to perform crucial operations seamlessly from the command line.

Integrate Corcel, a library that provides Eloquent database models for WordPress, into our project. By incorporating Corcel, we can leverage the power of the Eloquent ORM (Object-Relational Mapping) to interact with WordPress database tables more seamlessly.

Tasks:

1. Install and set up Corcel as a dependency in our project.
2. Map the relevant WordPress database tables to Eloquent models using Corcel’s syntax and conventions.
3. Test the functionality of the Eloquent models by performing basic CRUD (Create, Read, Update, Delete) operations on the WordPress database.
4. Refactor existing code that interacts directly with the WordPress database to utilize the new Eloquent models instead.
5. Update the documentation to include information about the integration of Corcel and how to use the Eloquent models for WordPress database operations.

Expected Outcome:
Once this ticket is completed, we will have successfully integrated Corcel into our project, enabling us to utilize Eloquent models for WordPress database interactions. This integration will enhance code maintainability, readability, and the overall development experience by leveraging the familiar and powerful Eloquent ORM.

This ticket focuses on the evaluation and potential integration of the Sage Directives package into our framework (https://log1x.github.io/sage-directives-docs/). Sage Directives is a Composer package that provides a collection of useful Blade directives specifically designed for Sage 9. These directives cover a range of functionalities, including directives for WordPress, ACF (Advanced Custom Fields), and various miscellaneous helpers.

Tasks:

1. Perform a thorough review of the Sage Directives package, examining its features, documentation, and compatibility with our framework.
2. Assess the requirements and dependencies of the package, ensuring they align with our framework’s technology stack.
3. Evaluate the potential benefits and drawbacks of integrating the Sage Directives package, considering factors such as increased productivity, code readability, and maintenance.
4. Identify specific use cases or scenarios within our framework where the Sage Directives package’s Blade directives would be valuable.
5. Consider the possibility of forking the Sage Directives project if necessary to accommodate any customizations or modifications required for seamless integration.
6. Discuss the integration proposal with the development team, gather their input, and address any concerns or questions they may have.
7. Based on the evaluation and team feedback, make a decision on whether to proceed with the integration of the Sage Directives package.

Expected Outcome:
By the end of this ticket, we will have conducted a comprehensive assessment of the Sage Directives package’s suitability for integration into our framework. The evaluation process will provide insights into the package’s benefits, drawbacks, compatibility, and potential use cases within our application. The decision to integrate or not will be based on a careful consideration of these factors and the input from the development team.

This ticket involves creating an abstraction for the “Ajax” class, which will facilitate interaction with the WordPress API. The goal is to base or draw inspiration from Laravel’s Events and Listeners, leveraging Laravel’s API for testing Ajax events in the Artisan console. The “Ajax” class should handle scenarios where the Ajax action needs to be executed for logged-in users, non-logged-in users, or all users.

Tasks:

1. Develop a new “Ajax” class that encapsulates the functionality for handling Ajax requests within the WordPress environment.
2. Draw inspiration from Laravel’s Events and Listeners to design an intuitive and extensible approach for registering and handling Ajax events.
3. Implement methods and properties within the “Ajax” class to support event registration, event listeners, and event execution based on user authentication status.
4. Integrate the “Ajax” class with the existing codebase, ensuring proper setup and initialization for handling Ajax requests within the WordPress environment.
5. Utilize Laravel’s API or a similar approach to enable testing of Ajax events in the Artisan console, providing a streamlined development experience.
6. Update the documentation to include comprehensive information about the usage of the “Ajax” class, event registration, and handling Ajax requests based on user authentication status.

Expected Outcome:
Upon completion of this ticket, we will have an abstraction for the “Ajax” class that simplifies interaction with the WordPress API. Drawing inspiration from Laravel’s Events and Listeners, the “Ajax” class will provide a seamless and familiar approach for registering and handling Ajax events. Developers will be able to test Ajax events using Laravel’s API in the Artisan console and easily manage the execution of Ajax actions based on user authentication status (logged-in, non-logged-in, or all users).

This ticket focuses on updating the existing Laravel Auth connector to make it compatible with WordPress. The current implementation, which worked with Laravel version 5, needs to be revised and adapted to function seamlessly with Laravel version 10 while maintaining its compatibility with WordPress authentication mechanisms.

Tasks:

1. Review the existing implementation of the Laravel Auth connector that worked with Laravel version 5.
2. Analyze the changes introduced in Laravel version 10’s authentication system, considering adjustments needed to align the existing connector.
3. Update the connector class located in the “src/Auth” directory to reflect the changes in Laravel version 10 while ensuring compatibility with WordPress.
4. Validate the compatibility of the updated connector by testing its functionality with WordPress authentication and user management features.
5. Address any issues or conflicts that arise during the integration process between the updated connector, Laravel version 10, and WordPress.
6. Update the documentation to include information about the updated Laravel Auth connector, its compatibility, and instructions for integration with WordPress.

Expected Outcome:
By completing this ticket, the Laravel Auth connector will be updated to be compatible with both Laravel version 10 and WordPress. The connector class within the “src/Auth” directory will be revised to accommodate changes in Laravel version 10 while retaining its functionality with WordPress authentication. The updated connector will provide a seamless experience for users requiring authentication with WordPress in a Laravel 10-based application.

This ticket involves creating a base theme to demonstrate the functionality of Pollen Framework, utilizing TailwindCSS, AlpineJS, and Blade templating syntax. The theme’s asset compilation will rely on Laravel 10’s implementation of ViteJS, offering an efficient development experience.

Tasks:

1. Install the necessary dependencies, including Pollen Framework, TailwindCSS, AlpineJS, and Laravel 10’s implementation of ViteJS.
2. Create a new theme directory and structure within the project, following Pollen Framework’s conventions.
3. Configure TailwindCSS and AlpineJS within the theme to optimize their functionality.
4. Implement a sample set of Blade templates that showcase the features and capabilities of Pollen Framework.
5. Utilize ViteJS to handle the asset compilation and build process for the theme, ensuring efficient development workflows.
6. Test the theme by rendering the sample Blade templates and validating the integration of Pollen Framework, TailwindCSS, and AlpineJS.
7. Document the theme’s features, usage instructions, and any configuration details required for seamless setup and customization.

Expected Outcome:
Upon completing this ticket, we will have a base theme that demonstrates the usage of Pollen Framework with TailwindCSS, AlpineJS, and Blade templating. The theme will utilize Laravel 10’s implementation of ViteJS for fast and efficient asset compilation. Developers will be able to explore the functionality of Pollen Framework, experiment with Blade templates, and leverage the power of TailwindCSS and AlpineJS within the context of the theme.

This ticket aims to implement an “Asset” facade that will streamline the injection of CSS stylesheets and JavaScript resources on various parts of the website, including the frontend, backend, WordPress login page, and the WordPress content editor. The facade will allow developers to easily manage asset injection using WordPress’s built-in functions, with the added flexibility of specifying injection location (head or footer) and leveraging ViteJS integration if desired.

Tasks:

1. Develop the “Asset” facade, including methods for injecting CSS and JavaScript resources into specific parts of the website.
2. Implement methods for specifying injection location (head or footer) when injecting CSS or JavaScript resources.
3. Integrate the Laravel Vite facade to allow for the injection of assets managed by ViteJS if the “useVite” method is called.
4. Create logic within the “Asset” facade to appropriately generate the necessary WordPress functions for asset injection based on provided parameters.
5. Test the “Asset” facade with various scenarios, including frontend, backend, WordPress login page, and content editor injections.
6. Ensure compatibility and proper functioning of the “Asset” facade when used in conjunction with ViteJS integration (Blade directive here: https://github.com/laravel/framework/blob/256f4974a09e24170ceeeb9e573651fd5e1c703e/src/Illuminate/View/Compilers/Concerns/CompilesHelpers.php#L58)
7. Update the documentation to provide detailed instructions on how to use the “Asset” facade for managing asset injection and ViteJS integration.

Expected Outcome:
Upon completion of this ticket, the “Asset” facade will be successfully implemented, allowing developers to manage the injection of CSS stylesheets and JavaScript resources across different parts of the website. The facade will support specifying injection location and enable seamless integration with ViteJS, leveraging the Vite facade provided by Laravel. This implementation will enhance developers’ ability to manage assets effectively, providing more control over frontend and backend styles and JavaScript resources.

Enhance the application by adding support for taxonomies through a Laravel configuration file. We will utilize the Extended CPT (Custom Post Type) library developed by John Billion for the implementation.

Tasks:

1. Create a new configuration file in Laravel to define taxonomies.
2. Implement the necessary changes to parse the configuration file and register taxonomies using the Extended CPT library.
3. Write unit tests to ensure the functionality of the taxonomies and the configuration file.
4. Update the documentation to include information about the new taxonomies and how to configure them.

Expected Outcome:
After completing this ticket, our application will have the ability to define and manage taxonomies using a configuration file, thanks to the Extended CPT library integration. This will provide a flexible and organized way to handle different taxonomy types and improve the overall extensibility of our application.

This ticket focuses on evaluating and potentially integrating the Orchestral Testbench package (https://packages.tools/testbench/) into our framework. The Orchestral Testbench package is designed to facilitate writing tests for Laravel packages, allowing package authors to benefit from Laravel’s testing utilities even when working outside of a complete Laravel application.

Tasks:

1. Conduct a comprehensive review of the Orchestral Testbench package, exploring its features, documentation, and compatibility with our framework.
2. Evaluate the requirements and dependencies of the package, ensuring they align with our framework’s technology stack.
3. Assess the benefits and drawbacks of integrating the Orchestral Testbench package, considering factors such as enhanced testability, ease of writing package tests, and maintenance.
4. Identify specific scenarios within our framework where the Orchestral Testbench package could be used to improve the testability of our codebase.
5. Consider the implementation process, including any necessary modifications or customizations to seamlessly integrate the package into our framework.
6. Engage in discussions with the development team to gather their input and insights regarding the potential benefits and challenges of integrating the Orchestral Testbench package.
7. Based on the evaluation and team feedback, make a decision on whether to proceed with the integration of the Orchestral Testbench package.

Expected Outcome:
By the conclusion of this ticket, we will have conducted a thorough assessment of the Orchestral Testbench package’s suitability for integration into our framework. The evaluation process will provide insights into the package’s benefits, drawbacks, compatibility, and potential use cases within our application. The decision to integrate or not will be based on a careful consideration of these factors and the input from the development team.

Evaluate and potentially integrate the Intervention package (https://github.com/darrenjacoby/intervention) into the project. The Intervention package aims to simplify the configuration of the WordPress admin interface and manage application state using a single configuration file.

Tasks:

1. Conduct a thorough review of the Intervention package’s features, documentation, and its compatibility with our existing WordPress application.
2. Evaluate the benefits and drawbacks of integrating the Intervention package, considering factors such as ease of configuring the WordPress admin interface and managing application state.
3. Examine the package’s usage instructions and understand how to create the configuration file.
4. Assess the suitability of the Intervention package for our project’s specific needs, considering factors such as flexibility, maintainability, and ease of use.
5. Discuss the integration proposal with the development team and gather their input and insights.
6. Determine the scope and extent of integration, considering whether to use the package’s default configuration or customize it to align with our project’s requirements.

Expected Outcome:
By the end of this ticket, we will have a comprehensive evaluation of the Intervention package’s suitability for integration into our project. The evaluation process will consider the package’s ability to simplify the configuration of the WordPress admin interface and manage application state using a single configuration file. The decision to integrate or not will be based on careful consideration of these factors and the input from the development team.