Magiiic.org

Category: Wordpress

  • W.R.A.P. – Web Reel Automated Publishing

    The W.R.A.P. plugin is a complement to W.R.A.P. by Magiiic platform, an online video-centric publishing service that includes fast processing, optimized streaming, editing, and organizing of provided content.

    This plugin serves as the administration tool for the service, allowing the management of user authentication on the external platform, groups (clients, companies, etc.), and projects.

    Although the plugin was created to complement a specific application, it has been designed generically to adapt to other third-party applications, assuming they are based on the use of subdirectories of the website.

    Features

    At this stage, the service provides:

    • Authentication API: Manage user authentication on the external platform, allowing a standalone application to benefit from WordPress user management.
    • Group Management: Organize users into groups (could be clients, companies, etc.) and manage their access.

    Roadmap

    • Project Management: Assign new projects to groups, show projects on group page.
    • Full Wrap libary: Integrate the current standalone Wrap project into the plugin.

    Requirements

    • A third-party web application or a part of the website not handled by WordPress, relying on document root subfolders.
    • WordPress should be installed in a subdirectory. Although not mandatory, a subfolder is a better approach for clarity and maintenance.

    This ensures that WordPress handles only the calls to its own structure and permalinks, while existing folders and files outside the WordPress directory are handled directly by the web server or the third-party application.

    Example File Structure

    Here is an example of how your file structure might look:

    /var/www/html/
├── wp/ # WordPress installed in a subdirectory
│   ├── wp-content/
│   └── ...
├── group1/ # Third-party application protected group
│   ├── .htaccess # Authentication rules for group1
│   ├── project1/
│   └── project2/
├── group2/ # Third-party application public group
│   ├── project1/
│   ├── project2/
│   └── private/ # Protected subdirectory
│   └── .htaccess # Authentication rules subdirectory
└── ...

    Installation

    1. Upload the plugin files to the wp-content/plugins/wrap directory, and activate as usual plugins.
    2. Go to Admin->WRAP->Settings screen to set the base URL of your external app (could be http://yourdomain.org/ or http://yourdomain.org/myapp/), and its local path (/var/www/html/ or /var/www/html/myapp/).
    3. Create groups, and assign allowed WP users.
    4. In the folders you want authentication, add a .htaccess file with the rules provided in the related group edit page, or adjust the example here: 
      <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_COOKIE} !wrap_auth_your-group=1
  RewriteRule ^(.*)$ https://yourdomain.org/wrap-auth/?redirect_to=%{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI} [L,R=302]
</IfModule>

      The first part of the URL must match an existing group, but the .htaccess file can be anywhere inside this group path (e.g., you can either protect the whole yourdomain.org/group1/ subsite, or leave it public and restrict access only to yourdomain.org/group1/private/).

    Usage

    Users visiting a page of the third-party app will be redirected if needed to the WP login page, and brought back to the page requested on success, otherwise get an error message.

    WordPress users have a profile page, where they can see the groups they belong to.

  • WP Package Updater – composer-ready library

    Used to enable updates for plugins and themes distributed via WP Plugin Update Server.

  • WooCommerce Virtual Less Fields

    Remove address fields on WooCommerce checkout page for orders with only virtual products.

    Ignores products identified as domain names with WooCommerce Domain Names plugin.

  • Sub Categories Widget

    Note: This plugin seems abandoned by it’s original author, so I took over to ensure maintenance if needed.

    Sometimes when you divide up your WordPress content into categories it all ends up in sub-categories of one or two main categories that don’t have any content themselves.

    With the widget you can add a list of sub-categories even if the parent doesn’t have posts.

    You can display and filter sub-categories in various ways:

    • Use the parent category as the widget title
    • Show post counts in bracket next to the name
    • Hide empty sub-categories
    • Add a link to the parent category to the widget title
    • Show the full sub-category tree so it include sub-sub categories and so on as well
    • Display the list as dropdown rather than as links
    • Use the first category of the current post as the parent
    • Exclude one or more sub-categories from the list
    • List the categories in reverse order

  • magiiic-autofeatureimage

    This is the long description. No limit, and you can use Markdown (as well as in the following sections).

    For backwards compatibility, if this section is missing, the full length of the short description will be used, and Markdown parsed.

    A few notes about the sections above:

    • "Contributors" is a comma separated list of wp.org/wp-plugins.org usernames
    • "Tags" is a comma separated list of tags that apply to the plugin
    • "Requires at least" is the lowest version that the plugin will work on
    • "Tested up to" is the highest version that you’ve successfully used to test the plugin. Note that it might work on higher versions… this is just the highest one you’ve verified.
    • Stable tag should indicate the Subversion "tag" of the latest stable version, or "trunk," if you use /trunk/ for stable.

    Note that the readme.txt of the stable tag is the one that is considered the defining one for the plugin, so if the /trunk/readme.txt file says that the stable tag is 4.3, then it is /tags/4.3/readme.txt that’ll be used for displaying information about the plugin. In this situation, the only thing considered from the trunk readme.txt is the stable tag pointer. Thus, if you develop in trunk, you can update the trunk readme.txt to reflect changes in your in-development version, without having that information incorrectly disclosed about the current stable version that lacks those changes — as long as the trunk’s readme.txt points to the correct stable tag.

    If no stable tag is provided, it is assumed that trunk is stable, but you should specify "trunk" if that’s where you put the stable version, in order to eliminate any doubt.

  • Grunt WP plugin tasks

    (formerly barely known as olib-dev)

    Dev libraries that might or might not be useful for WordPress plugins developers.

    See the sister project magicoli/grunt-translation-tasks to use in a generic project (using gettext insttead of WP-specific framework).

    Provides

    • makereadmetxt: Builds or updates the WordPress standard plugin readme.txt compiling and reformatting README.md, INSTALLATION.md, FAQ.md, CHANGELOG.md.
    • i18n: Prepares internationalization assets, updating text domains, generating POT, and converting PO files to MO.
    • makemo: Converts PO files to MO using WP CLI.

    Installation

    1. Clone the repository into your plugin’s subfolder (e.g., at dev/grunt-wp-plugin-tasks).
    2. Exclude this subfolder from distribution (e.g., add dev/grunt-wp-plugin-tasks to your .distignore).
    3. Add the following workspace configuration to your plugin’s package.json: 
      "workspaces": {
 "packages": [
   "dev/grunt-wp-plugin-tasks"
 ]
}
    4. Run "npm install" to install dependencies.
    5. In your plugin’s Gruntfile.js
      • Define your plugin slug name slug (e.g. ‘my-plugin’)
      • Load the custom tasks with: 
        // ...existing code...
const pluginName = 'YOURPLUGINSLUG'; // replace with your slug
require('./dev/grunt-wp-plugin-tasks/grunt-wp-plugin-tasks.js')(grunt, pluginName);
// ...existing code...
    6. Run "grunt" or invoke specific tasks (e.g., "grunt i18n") as needed.

  • grunt-translation-tasks

    Grunt tasks for managing translations and internationalization in PHP projects using standard gettext tools.

    Features

    • makepot (xgettext): Extracts translatable strings from PHP files into POT template
    • msgmerge: Updates existing PO files with new strings from POT file
    • makemo (msgfmt): Compiles PO files to binary MO files
    • i18n: Complete workflow – extract, merge, and compile translations

    Installation

    1. Clone this repository into your project’s dev folder: 
      git submodule add https://github.com/magicoli/grunt-translation-tasks dev/grunt-translation-tasks
    1. Add workspace configuration to your project’s package.json: 
      "workspaces": {
 "packages": [
   "dev/grunt-translation-tasks"
 ]
}
    1. Install dependencies: 
      npm install
    1. Load the tasks in your Gruntfile.js: 
      // Load translation tasks
require('./dev/grunt-translation-tasks/grunt-translation-tasks.js')(grunt);

    Usage

    Available Tasks

    • grunt makepot – Extract strings to POT file
    • grunt msgmerge – Update PO files with new POT content
    • grunt makemo – Compile PO files to MO files
    • grunt i18n – Run complete translation workflow

    Directory Structure

    Uses standard gettext directory structure:

    locale/
├── project-name.pot          # Template file
├── fr_FR/
│   └── LC_MESSAGES/
│       ├── project-name.po   # French translations
│       └── project-name.mo   # Compiled binary
├── nl_NL/
│   └── LC_MESSAGES/
│       ├── project-name.po   # Dutch translations
│       └── project-name.mo   # Compiled binary
└── ...

    Supported Translation Functions

    Extracts strings from these PHP functions:

    • _(), __() – Basic translation
    • _e() – Echo translation
    • _c(), _x(), _ex() – Context translation
    • _n(), _nx() – Plural translation
    • esc_attr__(), esc_html__() – Escaped translation
    • esc_attr_e(), esc_html_e() – Escaped echo translation

    Requirements

    • Node.js >= 14.0.0
    • Grunt CLI
    • Standard gettext tools (xgettext, msgmerge, msgfmt)

    Configuration

    The project name is automatically detected from your package.json. You can customize paths and options by modifying the task configuration in your Gruntfile.js after loading the tasks.

  • WooCommerce Domain Names

    This plugin is designed for domain names resellers. Currently, it only provides the sale part, actual registration has to be done manually.

  • magicoli/woocommerce-bookings-sync-unpaid

    Include unpaid bookings in Google Calendar synchronization, to ensure bookings waiting for payments are already blocked in external calendars.

    Useful if your policy is to set an option for booking requests, or if you collect payments later.

    This is a simple implementation, as documented on https://woocommerce.com/document/google-calendar-integration/#section-7

  • Project Donations for WooCommerce

    Collect donations for different projects with a WooCommerce product.

    If you are like me, you work on several projects and would like to simply collect donations for them, without bothering creating and configuring a product for each project.

    This plugin is mostly intended to be easy to set up. It is mostly usefull if you want to get donations and need or already use WooCommerce platform.