Goal: Create a persistent accounting information data store using the built-in WordPress Multisite database surfaces.
The table should follow some standard rules that will allow us to implement CRUD operations via REST endpoints in the MySLP Dashboard plugin.
Tasks
One time task “Create Or Update The Database” when the MySLP Dashboard version indicates a change.
Create a Monthly Ledger User Interface to allow for manual CRUD operations on the slp_accounting_monthly_history table.
Monthly History Data : Environment
Environment
All accounting history data will reside in tables for the main WordPress super admin account.
The Main WordPress Super Admin account site ID is stored in the PHP constant SITE_ID_CURRENT_SITE and should be 1. The database table prefix should come up as wp_ unlike user accounts that start with wp_<user_site_id>.
slp_accounting_monthly_history Table
The table should be named $wpdb->prefix . “slp_accounting_monthly_history” resulting in a table name of wp_slp_accounting_history.
slp_accounting_monthly_history Structure
ID – a unique ID to allow for explicit record I/O for CRUD operations.
KEY – a short string indicating the type of monthly data for example:
“SAAS_REVENUE”
“PLUGIN_REVENUE”
AMOUNT -an integer representing the numeric value for the key for example:
3500 which may represent “35.00” or 35 dollars in our UI surfaces
DATE – a date and time for they entry representing the date this value represents NOT when the data was created or modified
This Accounting Monthly History Data interface will run various monthly cron jobs to collect data and store it in this table. We will use this data to product things like monthly revenue graphs for the SaaS Account Overview dashboard. The graph will show SaaS Revenue from active accounts on a monthly basis.
We will do the same providing a manual process to add other revenue such as WordPress plugin revenue under “PLUGIN_REVENUE” keys.
We will allow for users to change the Line Chart revenue graph to show “monthly” or “yearly” graphs. Future data keys may warrant daily graphs.
Task: Create Or Update The Database
When the MySLP Dashboard module version (plugin version) changes, run a database “create or update” hook to create the table or modify it as needed.
Copy the design pattern in the Store Locator Plus plugin in the \SLP_Admin_Activation class. wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Activation.php This is fired from \SLPlus::initialize_after_plugins_loaded When the Store Locator Plus version reported is newer than the installed version for the plugin (see version_compare( $this->installed_version, SLPLUS_VERSION, ‘<‘ )) , the MySLP Dashboard should follow that pattern.
Task: Monthly Ledger User Interface
Admin Menu
Add a submenu with the label “Monthly Ledger” under the “Accounting” admin sidebar menu we created in \MySLP::create_network_admin_menu.
Add a new My MySLP_Account_MonthlyLedger PHP React loader and helper class. Follow the design pattern of \MySLP_Accounting in wp-content/plugins/myslp-dashboard/include/accounting/MySLP_Accounting.php Place it in the same directory as MySLP_Accounting.php as a sibling.
Create a new React component that allows basic CRUD operations on the slp_accounting_monthly_history Table. Attach it to the MySLP_Account_MonthlyLedger PHP React loader. Follow the UI design pattern of the AccountingPanel React component at wp-content/plugins/myslp-dashboard/src/accounting/accounting.tsx Use a MUI X DataGridPro component as the primary table interface. Allow for pagination, starting with a default page length of 25 records. Sort the records by DATE descending on initial load so we see newer records at the top. Provide an add record interface where a user can enter the KEY, AMOUNT, DATE. Provide an inline edit record interface on the DataGridPro table to allow users to click on they KEY, AMOUNT, or DATE field on an existing record and change it. Provide a delete option for each record.
Data Interface
Use REST for all CRUD operations and to fetch the initial data set.
When records are added the backend data interface should:
Ensure all keys entered are trimmed (no leading/trailing spaces) and are shifted to uppercase.
AMOUNT is stored only as an integer.
DATE field needs to allow for flexible input converting text input into a best guess for the date to be stored as a date-time entry in the database. Examples:
“05/2026” is May 2026 which should be recorded as the date time 2026-05-01 00:00:00
“05/01/2026” is May 1st 2026 which should be recorded as the date time 2026-05-01 00:00:00
“May 2026” is May 2026 which should be recorded as the date time 2026-05-01 00:00:00
Allow for various separators such as / or – or .
05-01-2026 is the same as 05/01/2026
05.01.2026 is the same as 05/01/2026
Use standard Date/Time JavaScript or React libraries for data manipulation.
The manipulation can be not the front-end (React/JavaScript) before communicating with the REST endpoint.
The backend should do basic sanitation before recording data.
We are creating a full Store Locator Plus accounting dashboard to track both the SaaS platform as well as WordPress plugin sales.
Sales Data
The primary source of truth for sales data will come from Stripe. Any references to PayPal payments or accounts can be considered legacy information and can be left out of the accounting panel.
The payment module holds the Stripe API module and related code for payment system communications.
User Interface
Stage 1 : Accounting Overview Scaffolding
Accounting Sidebar Menu
A new sidebar menu should be created in WordPress for super admin users only. \MySLP::create_network_admin_menu should be used to create and attach the menu. Follow the design pattern for the configure menu option, code snippet follows:
Unlike the main configure menu page that is rendered via \MySLP::render_configuration_page the new accounting module should load and render a React PHP helper class. We want this interface to be primarily React driven.
The WordPress PHP React Helper Class
Follow the \MySLP_Customer_Profile class for guidance on implementing a React user interface within WordPress. I suggest creating a new class MySLP_Accounting in wp-content/plugins/myslp-dashboard/include/accounting.
The React AccountingPanel Component
The React components that \MySLP_Accounting loads with the help of the wp-scripts node package should live in wp-content/plugins/myslp-dashboard/src/accounting. This directory should have a block.json and an accounting.tsx file.
block.json should probably look like this:
{
"script": "file:profile.js"
}
The accounting.tsx TypeScript should contain the React accounting component. This new React component should be named AccountingPanel. It should follow the UX design pattern of the ProfilePanel component in wp-content/plugins/myslp-dashboard/src/profile/profile.tsx
The initial user interface will only have a single submenu (SLPTabsBar Tabs components) for the main page which should be labelled “Overview” which is already selected and open. It will render the AccountingOverviewPanel component noted below.
AccountingOverviewPanel Component
A supporting AccountingOverviewPanel React component should be created. If the WordPress wp-scripts supports it, this can go in the same directory as the AccountingPanel component : if not place it in wp-content/plugins/myslp-dashboard/src/accounting_overview
This component should be a React Dashboard that shows overall accounting metrics. To start with we will want to show the total number current active accounts and total amount of payments from those active accounts. The ManageCustomers React component (wp-content/plugins/myslp-dashboard/src/manage_customers/manage_customers.tsx) displays this data in the AdminHeader children via a pair of Chips. Use the same REST endpoints to fetch this data and display it.
Here is a screen shot of the Material UI Dashboard Template that is referenced.
For now we need the cards for:
Accounts in place of Users with the active count below. We will add a data table for historical trends and a graph below it in the future. Clicking on the user count in the account card should redirect the UX to load the Manage Customers page at /wp-admin/network/admin.php?page=customer_list
Payments in place of Conversions with the total payment amount below. This too will eventually have trends stored in a data table that we will create later.
AI Summary
Junie Pro Summary
Completed setup and implementation prep for the accounting dashboard work in myslp-dashboard, including running required start-revision on branch accounting.
• Implemented Stage 1 accounting UI scaffold: new Accounting admin page, React entrypoint, and overview metrics/cards with click-through to Manage Customers.
• Added new files: include/accounting/MySLP_Accounting.php, src/accounting/accounting.tsx, and src/accounting/block.json.
• Updated integration points in include/MySLP.php and constants/version metadata in myslp-dashboard.php and package.json.
• Validation status: lint checks for new files passed (only a non-blocking TS import style warning noted earlier), diff checks passed, and you confirmed npm install + npm run build succeeded locally with generated build/accounting/accounting.js and build/accounting/accounting.asset.php present.
• Environment note: Junie shell still lacks local php tooling and direct GitHub auth; you requested follow-up guidance on PAT-based auth after task completion.
Junie Release Notes • Scope: No new product-code changes were made after the previously summarized accounting dashboard work in myslp-dashboard. • Skills/Environment updates this session: Reloaded skills via Vendors/JetBrains/relink_skills.sh; available skills now include /wordpress-release-notes. • Code impact since last implementation summary: None. • Build/Test status: No additional build or test runs were performed after the earlier confirmed successful npm install and npm run build for myslp-dashboard. Included Previously Completed Work (for continuity) • Added Accounting admin page scaffold and React entry (include/accounting/MySLP_Accounting.php, src/accounting/accounting.tsx, src/accounting/block.json). • Wired menu/render integration in include/MySLP.php and version bump artifacts from start-revision (myslp-dashboard.php, package.json).
homeUrl most likely comes from the PHP class \MySLP_Manage_Customers::extendReactVars set to WordPress get_home_url()
REST Backend
SaaS App backend via MySLP Dashboard plugin.
— Fetching Customers PHP method \MySLP_REST_API::register_routes defines the registered routes for WordPress. register_rest_route( $this->myslp_namespace, ‘/customers’,…) Calls the PHP method \MySLP_REST_API::get_customers
Location count is coming from $this->myslp->User->location_count
Root Cause Theory
This appears to be using a meta_query to fetch the user location data. This is NOT accurate.
In some cases the MySLP_User object does not have a location_count user_meta property set. If that is the case, it should call \SLP_Location_Manager::get_location_count for that user and store the result with
User Location Count Architecture
\MySLP_User::__get
Fetched from user_meta with the location_count property. This is likely where the AI decided to make this a source of truth for location counts.
case 'location_count':
case 'mapview_count':
$this->__get( 'user_meta' );
$this->$property = (int) ( $this->user_meta[ $property ][0] ?? 0 );
break;
\MySLP_REST_API::get_location_count_for_user
Currently unused anywhere in the project. This would ensure the app switched to the user’s blog and set_database_meta() then called: \SLP_Location_Manager::get_location_count
\SLP_Location_Manager::get_location_count
This is the original method from the legacy app code to fetch location counts. It queries the custom SLP database that is added for every user to get the count of records. It comes from the linchpin Store Locator Plus base plugin.
With the SaaS dashboard there is a Manage | Customers option that displays the customer list. It is using a default WordPress table style presentation that has been modified by one of the SaaS plugins, most likely MySLP Dashboard (myslp-dashboard). I would like to make improvements to this interface.
Sadly, some of the accounts like “ranger_creek” are not longer available and are not able to show the issue. It is difficult finding which accounts reproduce the errors and where.
I had to update the stripe connection which meant rewriting how subscription processing is managed including cancellations.
So for the customer mcampbell_at_tnwebtech_dot_com (830.828) this is what I have as the status: original subscription 24th last renewed feb 24th cancelled mar 6th stripe charged them mar 6th AND marked it cancelled april 6th it should have marked the 24th subscription to cancel on mar 24th
Current status according to Stripe: they have set their account to cancel on April 5th Current subscription: *z8ku is deleted on Stripe now meaning it will not auto-renew
Please ensure that is what they want.
From the Stripe history: The original subscription *9h4z Started Oct 24 2023 Cancelled via SLP Dashboard on Mar 6th 2026 at 1:05AM (server time) Was set to stop providing SLP maps on Mar 24th 2026 They then renewed (created the new subscription) Mar 6th at 1:08AM (server time) This is set to expire on April 5th 2026
Yes, we have an issue with RENEW If the prior subscription is still active (*9h4z in this case) it should set the new subscription (renewal) to start when that ends (Mar 24th 2026 06:21AM server time) The bug is that is started immediately , thus the new 6th to 5th dates That is OK for renewals that happen AFTER the maps are disabled (most users) but in this unique situation it needs to be addressed.
Flexible Recommended: Provides accurate and predictable billing behavior and new capabilities. To access these improvements, which are only available in flexible billing mode, you must create new subscriptions with flexible billing mode or migrate your existing subscriptions.
*Classic: Uses the existing Stripe subscription behavior. This setting is maintained for backward compatibility with older integrations.
AI Resolution Assistance
Prompt
@Amelia -
In the MySLP Payments module (WordPress/wp-content/plugins/myslp-payments) there is an issue related to renewing cancelled subscriptions.
__
Make a note of this as general knowledge about the Store Locator Plus Saas Application:
- local (https://local.storelocatorplus.com) and staging (https://staging.storelocatorplus.com) servers may be using outdated data sets
- local and staging servers employ the Stripe TEST environment and related keys
- the production server uses live keys
- NEVER run tests against live Stripe customer data using live keys even on the staging or local servers
__
The following scenario is a real-world situation which played out on the production version of the SaaS application.
We have an issue with RENEW subscription.
- If the prior subscription is still active (sub_1O4dzSBvHKfBw2LGsKZp9h4z in this case) it should set the new subscription (sub_1T7rZBBvHKfBw2LGODU6z8ku) to start when the still-active subscription ends (Mar 24th 2026 06:21AM server time).
- The bug is that the new subscription started immediately setting a March 6th start date when an April 5th end date.
- The new subscription should have started on March 24th 2026 at 6:21AM.
- If the prior subscription is past the end (cancel_at) date, only then should the renewal start immediately. That was not the case in this situation.
Meta data about the customer and their interaction with the application:
customer: mcampbell@tnwebtech.com
Current status according to Stripe: they have set their account to cancel on April 5th
Current subscription: *z8ku is deleted on Stripe now meaning it will not auto-renew
Please ensure that is what they want.
From the Stripe history:
The original subscription *9h4z
Started Oct 24 2023
Cancelled via SLP Dashboard on Mar 6th 2026 at 1:05AM (server time)
Was set to stop providing SLP maps on Mar 24th 2026
They then renewed (created the new subscription) Mar 6th at 1:08AM (server time)
This is set to expire on April 5th 2026
AI Fix
in \stripe\MySLP_Stripe_Payments::renew_subscription add the trial_end argument.
// If the old subscription still has remaining paid time, defer the new
// subscription so it starts when the old period ends.
$prior_period_end = $this->subscription->current_period_end ?? null;
if ( $prior_period_end && $prior_period_end > time() ) {
$args['trial_end'] = $prior_period_end;
}
try {
$this->subscription = Subscription::create( $args );
E2E Testing
Write a new E2E Test Specification "subscription_renewals".
The first test in the specification needs to test "Can renew a subscription before it has expired".
This is a corner case with some specific requirements.
- Login as a user with a current active subscription
- Go to My Profile and look for the current subscription ID, remember this value
- Go to My Profile and cancel the subscription
-- The current Stripe subscription ID should be posted and marked in Stripe as canceled
-- The current subscription should have a cancellation date at the end of the current period
- Go to My Profile and renew the subscription
-- This should create a new Stripe subscription ID
-- The new Stripe subscription ID should start when the current period ends
-- The new Stripe subscription should NOT start at the date/time of the renewal
-- The new Stripe subscription should be set to renew in a month (current period ends a month later)
Contains the map and other data that drives SLP for each country. ccTLD is the region parameter for Google Maps ccTLD is any of the Unicode region subtag identifiers
