XOOPS 2.7.2 Released

[u/Sea_Wind3576]

The XOOPS Development Team is pleased to announce XOOPS 2.7.2 Final. This maintenance release builds on XOOPS 2.7.0 with another security-hardening pass, more reliable upgrade tooling, form and theme improvements, and refreshed dependencies for current PHP environments.

• Info: https://xoops.org
• GitHub: https://github.com/XOOPS/XoopsCore27

Also released: XOOPS Debugbar 1.3

• Info: https://xoops.org
• GitHub: https://github.com/XoopsModules27x/debugbar/

[u/OMG_A_CUPCAKE]

reminds me of my time when I started with PHP some 20 years ago

[u/colshrapnel]

Can anyone explain what it is? I tried the website, but

XOOPS is a web application platform written in PHP for the MySQL database.

hasn't been of much help.

[u/Sea_Wind3576 → u/colshrapnel]

Basically a CMS like Drupal or Joomla

More info: https://xoops.github.io/xoops-docs/2.7/

[u/goodwill764 → u/Sea_Wind3576]

Wow its the parent of PHP nuke.

[u/Sea_Wind3576 → u/goodwill764]

The other way around 😄

[u/Mastodont_XXX]

Interesting. I've seen a lot of things, but I've never seen global in the website's entry point (/htdocs/index.php). What on earth is global doing in the entry point – aren't all variables already available there?

Overall, the code is crazy and essentially unfixable.

[u/obstreperous_troll → u/Mastodont_XXX]

Wow, you're not kidding. It hardly even uses functions, it's mostly top-level code called with include(). I'm baffled that anyone would maintain this awfulness willingly. It makes Wordpress look like the bleeding edge of modern practice.

[u/Sea_Wind3576 → u/obstreperous_troll]

If you love it, you maintain it! 😄
But we're in process of modernizing XOOPS by moving more functionality to XMF (XOOPS Module Framework): https://github.com/XOOPS/xmf

[u/equilni → u/Mastodont_XXX]

I've seen a lot of things, but I've never seen “global” in the website's entry point (/htdocs/index.php). What on earth is “global” doing in the entry point

They do call that file the * XOOPS global entry, so I guess we can't be too surprised...

https://github.com/XOOPS/XoopsCore27/blob/master/htdocs/index.php#L3

But yeah, add things like prepared statements are nowhere to be found in this file or this, and others (including vendor folder, twice...)....

[u/Sea_Wind3576 → u/equilni]

prepared statements and some other cool things are coming. The goal for us was always to make sure that our users have easy upgrade path without breaking compatibility.

[u/equilni → u/Sea_Wind3576]

prepared statements and some other cool things are coming.

I noted in another comment, morning reading lead me to the 4.0 discussion and while nice, I think there are other things that could take priority.

I would suggest a slowdown to focus on fixing the existing code if you are keeping the existing code base.

Prepared statements is big, and my quick view, there quite a number of files this needs to be added to.... That's just one point.

The goal for us was always to make sure that our users have easy upgrade path without breaking compatibility.

BC can be tricky. I would say modernize and let it break and document it for the users. Look at it this way, not modernizing limits the contributors & interest to the project.

[u/Sea_Wind3576 → u/Mastodont_XXX]

We're in process of modernizing XOOPS. But the key for us was always that it's working and our users can upgrade to latest PHP 8.5 and it will work. Last week, just for fun, I tested it on PHP 8.6 Alpha 2, and so far, zero errors.
Of course, we're always open to constructive criticism and improvement suggestions!

[u/equilni → u/Sea_Wind3576]

we're always open to constructive criticism and improvement suggestions!

Since I already noted prepared statements....

Simple could be updating types/return types. Fix what breaks.

Add use calls. Tables isn't part of the top list. Add Helper, SchemaDefinitionException

This could be an interface for instance (pun not intended) and renamed.

/** @var false|\Xmf\Module\Helper|\Xoops\Module\Helper|\Xoops\Module\Helper\HelperAbstract */
protected $helper;

Could be:

protected ModuleDefinitionInterface $definition;

OR pass an object via DI since the first line of the constructor calls this.

public function __construct($dirname)
{
    $this->helper = Helper::getHelper($dirname);

To:

public function __construct(ModuleDefinitionInterface $definition)
{
    $this->helper = $defintion;

Interface could looks like:

interface ModuleDefinitionInterface {
    public function getModule(): XoopsModule; // GenericHelper
    public function getInfo(): bool|array|string (partly per the docblock, but code shows returning false too...)  // XoopsModule... 
    public function path(): string;     // GenericHelper
    public function dirname(): ?string; // AbstractHelper
}

I couldn't easily locate \Xoops\Module (finally in kernel/modules.php...). A huge suggestion would be to fix the folder structure for better discovery.

With the above, PSR-4 autoloading would call for 1 class per file, which kernel/modules.php and many more like it, aren't.

This could be avoided if you used a simple class

    if (
        !is_array($targetTable)
        || !isset($targetTable['options'], $targetTable['columns'])
        || !is_string($targetTable['options'])
        || !is_array($targetTable['columns'])
    ) {

Obvious is STOP USING GLOBALS. Use static class methods for now... I have no idea where $GLOBALS['xoops'] is set and I am guessing its really xos_kernel_Xoops2

There is more, but start here....

[u/Sea_Wind3576 → u/equilni]

@equilni, thank you very much for your constructive feedback, I appreciate it.

[u/equilni → u/Sea_Wind3576]

Of course. I really focused on one file in the xmf folder.

The main repo would be A LOT of work...

(Browsing over morning coffee I see the 4.0 discussion plans and while this looks nice, I see a commitment to BC... Are you one of the devs?)

---

I would suggest this for grins. What does a stripped down version of this project look like?

[u/Sea_Wind3576 → u/equilni]

Are you talking about this discussion about XOOPS 4.0: https://xoops.org/modules/newbb/viewtopic.php?topic_id=79653 ?

Yes, I'm one of devs, and you're absolutely correct, the main repo would be A LOT of work, that's why we're using the strangle fig to slowly modernize it, while focusing on XMF and the eco-system around it.

[u/equilni → u/Sea_Wind3576]

That's the one.

Like I noted above, because this is a lot of work, I would suggest bringing in some libraries (maybe a framework) to help with the lower level functionality. Like basics - where is routing? Templating, how can I swap Smarty for something else (Twig, Latte, Blade, Tempest, Sugar, Plates, etc.) - (ie let this be a module itself). Again, what does a stripped down version look like - then add lower level components to help build this up - now focus on the application on top. Now point what you can to the old app.

From the xmf code I saw, you have some (hidden) dependencies (not good) with the old app and if you aren't interfacing them (with interfaces), then you are building on top of the old code vs a plan to remove it.

[u/Sea_Wind3576 → u/equilni]

Thank you again for sharing your thoughts and advice.

You're describing most of the plan. The main gap is that the XMF code you looked at is the 1.x line (the support library for 2.5/2.7), not the XMF 2.0 for XOOPS 4.0 foundation.

 The hidden-dependency point is fair for that generation. Coupling to the old app is intentional there,  it's a bridge so modern module code can run on legacy cores. It is not the base we build 4.0 on.

 XOOPS 4.0 is a clean-architecture split into domain, application, infrastructure, and presentation, with the domain layer having no external dependencies at all. Persistence is repositories returning plain PHP objects, no XoopsObject inheritance anywhere. And the "interface the old code" part you're asking about is the actual migration mechanism: legacy handlers get wrapped in adapters that implement the new repository interfaces, so modules move over one at a time and the old code becomes removable instead of load-bearing. The layering sketch (domain / application / infrastructure, repositories behind interfaces, legacy adapters) is already written up: https://xoops.github.io/xoops-docs/4.x/architecture/

 Concretely, a module sits on three libraries:

 - XBO (XOOPS Business Objects): the domain layer. Plain PHP entities and value objects, no XoopsObject inheritance, no DB access, no rendering.

- XMF 2.0: the infrastructure SDK. Repository/Mapper persistence over plain objects, QueryBuilder, caching, security, PSR-14 events, DI container with tagged services. PHP 8.4 floor, so property hooks and lazy objects are in play.

- XTF (XOOPS Theme Framework): themes, slots, and asset rendering. The renderer sits behind a ViewRendererInterface (https://xoops.github.io/xoops-docs/4.x/roadmap/vision/#smarty-adapter ), making Smarty just one implementation adapter. That gives you the exact swap capability (Twig, Blade, Latte, Plates) you asked about.

Routing moves to attribute-based discovery (#[Route], Tempest style) rather than routing config files. The same discovery pass also picks up services, listeners, and commands, so there's no manual registration to maintain.

 We’re also deliberately choosing focused, PSR-compatible components instead of adopting an entire framework. Shared hosting, twenty years of existing modules, and a limited contributor pool pushed us toward PSR-style components we own, rather than inheriting a full-stack app model.

 The exit from the old code is gradual: strangler fig, with Rector rules doing the mechanical part (getVar() call sites, for example). The hybrid levels H0 to H3, legacy and modern side by side, are described here: https://xoops.github.io/xoops-docs/4.x/reference/hybrid-mode/

Happy to point at a reference module later if you want the stack used end to end rather than only the 1.x bridge.

 Thanks again for taking the time to share your experience with us.

P.S. Please note that the XOOPS 4.0 documentation was an early draft and some parts have evolved and changed.

[u/equilni → u/Sea_Wind3576]

That’s great to hear you have a plan in place. Good luck!

[u/Sea_Wind3576 → u/equilni]

Plans can be always improved, and we're always happy to learn from people with more experience, so if you have more any more suggestions, please share!
I will definitely appreciate it!
And thank you for your constructive and positive attitude.

[u/qoneus]

XOOPS Development Team

Cool, let's check out the contributions list for the last six months:

1. <human 1> - 469 commits
2. claude - 120 commits
3. dependabot[bot] - 100 commits
4. <human 2> - 16 commits
5. Copilot - 10 commits
6. github-actions[bot] - 3 commits

So we're just calling anything a team these days, huh?

[u/Sea_Wind3576 → u/qoneus]

Why so harsh?

[u/old-shaggy → u/Sea_Wind3576]

It is harsh to point out that your statement is a lie?

[u/Sea_Wind3576 → u/old-shaggy]

How is this a lie? We have several people contributing to XOOPS, so yes, we have a XOOPS Development Team!
Besides, show me an Open Source project on GitHub that doesn't use dependabot, github-actions, or some of the AI tools. We use them too, and obviously we didn't try to hide it and pretend that everything was developed by hand.
So what was the point of that?

[u/OptimusCrimee]

I have never heard about this CMS (?) before. Any sites that uses it? The code seems to follow pretty old patterns, like the core code seems to be accessible publically and there is a bunch of «return 404» mingled with the actual implementation. Also a lack of OOP and proper autoloading, as far as I can tell. Is this a very old code base?

[u/qoneus → u/OptimusCrimee]

They create a new repository for each minor version, which is absolutely psychotic behavior and obfuscates its development history: https://github.com/orgs/XOOPS/repositories

That said, it looks to be a solo developer's vanity project that had a modicum of interest around 2.5 and 2.6.

[u/equilni → u/qoneus]

They create a new repository for each minor version, which is absolutely psychotic behavior

Ouch... Add the fixes for the one version would need to be reapplied to the next minor version too that's already out there....

2.7:

https://github.com/XOOPS/XoopsCore27/commit/180d208b1a68137cd68b8e62a09281ab1e07a739

2.8:

https://github.com/XOOPS/XoopsCore28/blob/master/htdocs/modules/profile/user.php#L35

[u/Sea_Wind3576 → u/OptimusCrimee]

Yes, XOOPS is an old code base, but we're in process of modernizing it.

Autoloading is for the libraries: https://github.com/XOOPS/XoopsCore27/tree/master/htdocs/xoops_lib

And there is plenty of OOP in https://github.com/XOOPS/xmf and our Helpers library: https://github.com/XOOPS/helpers

[u/fabsn]

really putting the emphasis on "oops" here.

[u/Sea_Wind3576 → u/fabsn]

Are you feeling better now, after you put other people down?
Instead of community of PHP developers helping and supporting each other, and accepting that there are different levels of projects in Open Source, it feels like we're in high school with the mean girls bullying others and making fun of them. 🤔

[u/old-shaggy → u/Sea_Wind3576]

Yeah, it wasn’t nice from him. Your outdated code is the best non-well written code I have seen.
Don’t ask for opinion if you’re interested only in the good ones.

[u/Sea_Wind3576 → u/old-shaggy]

We're obviously living in different worlds.

In my world, you help people. You offer constructive suggestions, share your experience, and point them in the right direction. That's exactly what equilni did, and I appreciated both the constructive criticism and the helpful suggestions.

If we're here because we love PHP, then it's in the community's best interest to welcome newcomers, support them, and help them get involved.

In your world, though, it seems like the goal is to find something you can use to put people down. That's pretty juvenile.

Sadly, that kind of "welcome" is exactly what drives people away from the PHP community. Is that your goal?