Thanks for testing!

It depends on the configurations, but usually I usually see fatal PHP errors in the apache log.

I'm having trouble locating a definitive version of animal or pedigree.

It does not look like any version I've found has had a PHP7 conversion done. It uses a lot of direct mysql calls that will be fatal errors. It looks like it would install under PHP 7, but then not work when accessed, so I continued testing under PHP 5.6.

I tried Pedigree 1.30 Beta1 from the sourceforge module repository, and it seemed to work.

I also tried Pedigree 1.31 Alpha 5 from github, and got blank content when entering. It showed an error with loading a template. I submitted a PR to fix that, so it should be available once someone can do a quality check. It may be a little while until the PHP 7 compatibility is done.

I would like to see the version you are having issues with if it is something not covered above.

Ouch, apparently we need to fix some instructions :(

Some templates changed, so things will be messy in admin until the system module is updated. You can jump straight into it with this:

your-site-url/modules/system/admin.php?fct=modulesadmin&op=update&module=system

But, there still is a problem. With 2.5.8 there are small but vital database changes, so you need to install and run the upgrade code from the distribution to handle the modifications.

These are the instructions from the 2.5.8 RC announcements that pick up from where you seem to be:

Quote:

We do need to check the instructions and make sure they indicate the correct procedure. It has been a while since the updgrade was required, so there is some confusion there. Sorry.

I just did a fresh install from 2.5.7.2 straight from SourceForge on PHP 5.6.11. No issues.

I'm not sure what to suggest if there isn't even an error in the server logs.

What else is installed besides the base XOOPS? Are the installed PHP extensions the same between your 5.5 and 5.6?

The changes in 2.5.7.2 were pretty limited, so I'm surprised if it was a new issue there. But if it is broken, it needs fixed. Anything that could help reproduce the error you are seeing would give us a place to start.

Sorry, never saw this one.

Actually, the problem seems to be that it should always merge the selected user (or users) with the larger result set produced and cached. Seems to have been introduced with changes related to reducing some system crippling behaviors when the user table is large.

Again, sorry. I'll get an official fix in the works.

You might look at fbcomment module. It was written to allow per article customization of the open graph presentation to facebook. Maybe it can be useful, or give you some ideas.

I will mention, that facebook changes the rules on a regular basis, causing what worked yesterday to not work today In the fbcomment open graph editor, there is a button to check on what facebook actually sees, and what it thinks should be fixed. Every so often the module needs some tweaks to keep up with the changes. I've been busy with other things lately, so if anyone wants to give it some love, please do!

Interesting. I have a couple of observations.

Dude, use the current source on GitHub :) The sourceforge code is moldy -- lots of changes since then.

If you put this hook in to Model\Read you would never be able to trust the expected return from anything. Any installed module would be able to interfere with any handler no matter if it was the active module or not. Sounds like a free for all that could get unstable very easily, and that is not good.

Doing this to an individual handler (extending and method override) is trivial.

Combine that with the existing Events class (what XoopsPreload grew into,) and you can accomplish this with less collateral risk.

One of the improvements is the addition of Events::addListener(). You can dynamically listen for any event and have it invoke any callable. This way, you don't have to set up the listeners unless it is needed.

There is no triggerFunction(), but since there is always the chance of more than one listener, you could never really rely on which return value you would get. You would have to include a strategy to combine or choose from possibly multiple returns.

The existing triggerEvent() takes one argument, but that can be anything. Historically, that has often been an array, but using an object as the argument is often a better choice. For example, the psr4loader event brings the Psr4ClassLoader object with it, so the preload listeners can just register what they need -- the return is done through the passed object. Even a humble ArrayObject or SplQueue can be quite useful here.

Using a custom object for a complex result mechanism would allow you to more cleanly document what is actually occurring, making it easier to use and reuse the solution.

Put these pieces together, you can build something that doesn't open up so many potential issues.

I've responded to this issue on GitHub, where we track issues and resolutions.

https://github.com/XOOPS/XoopsCore/issues/373

Interesting points.

In 2.6, getBaseDomain() uses the public suffix list to parse the smallest registrable domain from a URL. There is an update script already, so keeping that up to date with a cron job is trivial. With a constant explosion of new TLDs and IDNs, this is a big issue, andhttps://publicsuffix.org/ is a valuable resource with industry wide acceptance. That an DNS lookups, and you've got what is needed.

Better control over the cookie domain, and the ability to serve assets from different domains are also in the works. A lot of the building blocks for more complex infrastructures are already going into place.

The idea of some generic mirror/peer list management built on that is interesting, although we want to make sure we are not just reinventing a CDN, and are actually adding value to the application portion of the stack. Writing a load balancing mechanism in PHP is probably not going to achieve the optimal result, just because of where it is in the stack when it is called, for example.

Interesting ideas, thanks.

I actually was looking at this recently. I don't have my notes available, but I'll try and cover what I remember.

As Mamba indicates, a large portion is dependent on the modules. A lot of them will have at least a common ancestor, so it is usually not hard to find a workable replacement. Even for things unique to ?????, some creativity with SQL can extract content in a form usable in another module.

The user conversion is a potential issue depending on the size (and temperament) of your user base. The password hashing has several salts, and is quite different from anything in any Xoops, current or future. The cleanest way to do it is basically mass invalidation, requiring every active user to go through the password reset mechanism.

The system I was examining was in the 1.2.x line, the 1.3+ variants introduced additional differences, but are still similar.

I would encourage you to keep us posted on your efforts. There is a certain level of animosity that you might run into occasionally regarding mentioning our competing "cousin." Personally, I have held "a best tool for the job at the time" attitude over the years, and so I've used a lot of things. But now, if XOOPS isn't the best tool for the job, that means I have work to do

If there are any major obstacles to moving back to XOOPS, I'd like to know what they are, and if practical, make them less of an obstacle.

Right now there is no support for Central Authentication Service in XOOPS.

There is an official phpCAS implementation, so it would be a matter of adding an authentication method that spoke CAS. It could probably leverage the existing provisioning mechanism.

If someone wanted to write this adaptation and contribute it, that would be great. While it sounds like a good enhancement, it is not likely to rise to the top of the list right now due to limited resources.

If the underlying authentication is AD, you could still have common authentication credentials, but not a true SSO.

This does sound like an interesting endeavor, and I wish you good luck!