REFACTOR: Update codebase following PSR4 standards

[patil-vipul]

Overview

Major architectural refactoring to align with modern PHP and JavaScript standards, introducing modular design patterns, comprehensive testing infrastructure, and improved developer experience.

Key Changes

Architecture & Code Organization

• PSR-4 Autoloading: Restructured codebase into inc/Modules/ with proper namespacing (OneLogs\Modules\Core, OneLogs\Modules\Rest, etc.)
• Interface-based Design: Introduced Registrable interface pattern, replacing singleton implementations for better testability and maintainability.
• Modular Structure: All modules now follow consistent architectural patterns with clear separation of concerns.

Build & Tooling

• Simplified Build Output: Migrated from assets/build/js to a flat build/ directory structure.
• TypeScript Support: Added full TypeScript configuration with strict type checking and path aliases.
• Modern Dependencies: Updated package.json with streamlined build scripts and current tooling.

Code Quality & Testing

• PHPUnit Integration: New phpunit.xml.dist configuration for automated testing.
• Static Analysis: Added phpstan.neon.dist for type safety and static analysis improvements.
• Enhanced PHPCS: Updated coding standards with VIP, PHPCompatibility, and Slevomat rulesets.

Plugin Bootstrap

• Simplified Entry Point: Refactored onelogs.php to use modern autoloader and constants approach.
• Improved Multisite Support: Enhanced uninstall.php with proper namespacing and function-based structure.

Checklist

• I have read the Contribution Guidelines.
• I have read the Development Guidelines.
• My code is tested to the best of my abilities.
• My code passes all lints (ESLint etc.).
• My code has detailed inline documentation.
• I have updated the project documentation as needed.

[patil-vipul]

@patil-vipul why logo part was not removed plus some of the feedback was closed without any clarification make sure to add some comment to clarify the purpose.

@up1512001 I’ve added clarification comments directly to the original feedback where it was first raised. Kindly review and share your response on the same thread for better context and tracking, instead of opening a new one. Thank you.

[patil-vipul]

@patil-vipul why marked resolved, I know for sure OneLogs don't require logo its copy=>paste from OD module without cleanup.

From my understanding, the logo field is a standard part of the shared site data used across OnePress modules. Since this was backported from the OD module, I didn’t remove it as I assumed we were keeping things consistent with the existing pattern.

Keeping this field doesn’t affect the UI/UX or any functionality of OneLogs, and it also helps with consistency across modules.

That said, if the you prefer to remove it here, I’m absolutely fine with doing so and updating the PR to move things forward.

cc: @justlevine

[justlevine]

@patil-vipul why marked resolved, I know for sure OneLogs don't require logo its copy=>paste from OD module without cleanup.

From my understanding, the logo field is a standard part of the shared site data used across OnePress modules. Since this was backported from the OD module [...]

1. I don't care about the logo itself. I think our OneDesign implementation is conceptually flawed (why would a user ever want to manually upload a site logo, and why aren't we automatically getting the site logo and other info from the health-check/connect process?), but it's a POC so who cares.

2. I do care about cross-repo interoperability + maintenance. Since we're not codesharing with libraries, I want any future developers to these projects to be able to quickly diff two files together and have it be obvious what is the "cross-One*" logic and what is plugin specific.

Elsewhere, the way I suggested balancing this was to keep the data structures in PHP (where array shapes are more temperamental), but leave it out of the frontend UX/UI. I'd argue that makes sense here
However, I can't at a glance tell if that makes sense here or determine the state/remaining effort of this PR because

3. Unless you've got explicit understanding with the creator of a comment thread, please do not mark a reviewer's comments as "resolved", and instead only reply e.g. with a commit ref.

   Has the frontend already integrated this change to satisfaction and now we're confirming necessity? Does evaluating the change still require significant amounts of code review, when we're already 2 days behind schedule? I don't have a quick way to find out, and while Utsav's executive function is probably larger than mine, im guessing he too still needs to dive through everything now to confirm.

Anyways, back to this specific discussion:

I defer to @up1512001 (with an internal preference for stripping it out of the UX/UI if doesn't slow us down too much more).

Going forward (here and the other One* refactors), if you see functionality in "shared code" that doesn't exist in the specific plugin, get confirmation whether it's a plugin-specific "quirk" or should be backported.

[up1512001]

@patil-vipul overall looks good to me added few nits.

[up1512001]

I defer to @up1512001 (with an internal preference for stripping it out of the UX/UI if doesn't slow us down too much more).

@justlevine While I understand this is POC work, I prefer we address this now rather than accumulate technical debt. These small issues become harder to fix later when they're embedded in the codebase. If stripping it from the UX doesn't significantly slow us down, let's do it properly from the start as its better to start with clean slate instead of cluttered one.

[justlevine]

I defer to @up1512001 (with an internal preference for stripping it out of the UX/UI if doesn't slow us down too much more).

@justlevine While I understand this is POC work, I prefer we address this now rather than accumulate technical debt. These small issues become harder to fix later when they're embedded in the codebase. If stripping it from the UX doesn't significantly slow us down, let's do it properly from the start as its better to start with clean slate instead of cluttered one.

Agreed, I'm deferring to you as to whether you think "stripping it" will slow us down here on this PR, since resolved comments aside you're the one with insight as to how much work is needed before we can merge and pass this to QA.

Which it sounds like you do, so let's strip it from the js and call it a day 🚀

[up1512001]

LGTM

[justlevine]

A few final nits, mainly to ensure we're not taking too much unintentional debt with us.

In general, please double-check and remove any now-unnecessary CSS classes (I don't expect you to audit if individual rules are still needed just classes that are no longer in use)

[justlevine]

I don't understand the shifting you did. why wouldnt the shared menu and menu screen be in our shared Admin namespace, instead of coupled specifically to the Logs Dashboard (one submenu screen + related assets).

[patil-vipul]

I was originally aligned with keeping the shared settings separate. However, based on today’s suggestion from @up1512001 to move this under the Logs admin, I made the shift accordingly.
If the preference is to keep it under the shared admin namespace instead, I’m happy to revert and align.

[justlevine]

Not finding that specific suggestion, so I'd assume he made that suggestion because he saw this was using LogsAdmin::SCREEN_ID, but didnt see that's because you moved the admin_menu and a lot of other shared handling to /Logs/Admin.php (which specifically handles the Logs Dashboard screen needs and not anything else).

LMK when you're done with the other files and i'll detangle those two classes.

[patil-vipul]

Here #4 (comment), and discussion over huddle for clarification.

[justlevine]

@up1512001 @patil-vipul PTAL at 1757392 which should hopefully clarify the separation of concerns between the shared Modules/Settings/* namespace and our Modules/Logs/* namespace.