Quote:

The whole family of ereg functions were removed in PHP 7. They had been deprecated since PHP 5.3.

Here is a stackoverflow explanation and recipe for replacing ereg():
https://stackoverflow.com/questions/6270004/how-can-i-convert-ereg-expressions-to-preg-in-php

The most likely cause of the error is some code in an old module which includes the phrase:
=& new

An example of this would look something similar to:


That syntax was deprecated in PHP 5, but is now an error in PHP 7. The "=&' is assigning a value by reference, but the return of "new" is already a reference. Remove the "&" and that should fix it.

It would be worth checking to see if any PHP 7 ready upgrades are available for any modules you may be using.

Install your stack (i.e. XAMPP or WAMP) and make sure it is working first.

Here is a section of the installation manual dealing with moving a site:
https://github.com/XoopsDocs/xoops-2.5.9-install-upgrade/tree/master/en/book/moving

You can follow those instruction to adapt your backup files to the local environment.

There are some potential issues. These are the main ones:

1) Since we expose Smarty directly, the BC layer for v2 would be required. It is good, but not 100% perfect. Alone, this would probably not be a blocker, but it could break previously working code.

2) Due to changes in parsing, things as simple as extra spaces or missing quotes may cause unintended results or errors in some circumstances. These were harmless in v2.

3) Many XOOPS templates have historically relied on an unassigned variable to evaluate as false. While this may still work, it will produce error messages, sometimes in log file filling quantities..

The code and templates included in XOOPS and the more actively maintained modules have some of these possible errors corrected already. There are, however more modules, and even more templates and themes that may never have been checked. Those are the ones that may break sites which have worked for years on upgrading.

With the 2.5 series, we want to encourage upgrades especially for security reasons. Adding features we suspect may cause issues is something we want to avoid if at all possible. The next generation XOOPS will include the latest Smarty, and as a major upgrade, the BC issues will be expected, acceptable and documented.

Quote:

Yes. That fixes the bug regarding the infinite redirection loop related to permissions to the start module.

It doesn't fix any underlying permission issues. Some known issues are handled in upgrade, but there can be problems since a lot has changed over time.

Bill, just out of curiosity, what was the version of the "antique xoops?"

This code is only used when a "Module for your start page" is specified. The permissions, either the group's "Module Access rights" for that start page module , or for the initial page content in the start page module is not allowing access.

There is an error in the redirect logic, but the group permissions for the module are what is preventing access. Make sure the registered user group has permissions to access the start module and it should work.

I will put in a patch for the redirect. It should redirect to user.php instead of to the start page.

This works fine (just tested on Ubuntu 18.04):



You should not be in xoops_lib when you run composer install. Also, XoopsCore does not contain a composer.lock file, so you might have better results starting from a fresh clone.

Installing composer globally is preferred over depending on the included composer.phar, but for now it will work if updated.

The message "Endroid Installer did not detect a compatible project type" is just informational. It is telling you that it didn't find a Symfony project to add itself to, which is as it should be.

For now, XoopsCore is targeted to developers only, and it is expected that developers have or will build their own proficiency with composer.

\XoopsFormRendererInterface defines the interaction between the business logic supplied by form elements and the presentation layer rendering of those elements. All HTML generated by core form and form element classes is done by an implementation of \XoopsFormRendererInterface.

\XoopsFormRendererBootstrap3 is a component supplied with core that provides a concrete implementation of \XoopsFormRendererInterface. A theme may optionally use that component. If the theme does not explicitly specify an implementation of \XoopsFormRendererInterface to use, the rendering choice will default to \XoopsFormRendererLegacy, which closely mimics the HTML generated in pre-2.5.9 form elements.

The separation through the interface makes the HTML generation the responsibility of the presentation layer, more specifically the theme. New and different renders are possible and expected, even for frameworks that have not been written yet.

To complete the separation, we need to stop passing the presentation detail directly from the business logic. This kind of detail belongs in the template where it can be adjusted by theme.

Let's roll this back a little bit, and examine what has changed and why.

As we worked on 2.5.9, a lot of effort when in to standardizing the display of system generated elements, and a special emphasis was given to Bootstrap based themes. Older modules, designed and coded long before there was a bootstrap framework, generally looked terrible. To be blunt, it generally looked like crap. The most common reason was due to bringing in CSS that was incompatible, causing serious visual breakage.

Newer modules, designed with bootstrap in mind, looked OK, but many themes came with a set of hacks to apply to the system and modules to fix some problems. Templates manipulated generated HTML to change elements, as well as add or remove attributes to make certain modules look better.

The problem was, not each theme had the same set of changes. So, each time a module was updated, different themes would break. If a module was reworked to look good under bootstrap, it broke when used with older themes.

The big problem, when we looked at it, was that PHP code (domain logic) was setting style attributes (presentation details,) and there was no way to override PHP code by theme. If it is set in the PHP code side, there is no way to know how the theme will interpret it. Some frameworks, such as Bootstrap, feature semantic classes rather than just visual classes, and that is good, but those semantics are unique to Bootstrap, and even specific versions of Bootstrap. Further, while Bootstrap enjoys wide adoption, it is far from the only scaffolding, and many find fault with it. If we code core to Bootstrap, we severely limit ourselves.

XOOPS inherently has a separation between logic, data and presentation. The Smarty template engine makes it possible to build a set of data in a PHP program that is passed to the engine, where the set of data is merged with a set of templates that control how the data is presented, and how it looks. XOOPS provides for themes which can override the templates provided by the module.

There are, unfortunately, places where PHP code belches out raw HTML, and thus becomes involved in the visual presentation aspects. The biggest example of those was the form elements. All the form element rendering was stripped out into classes implementing the \XoopsFormRendererInterface. The exact renderer used can be controlled by or overridden by the theme by specifying a theme_autorun.php file.

To achieve the goal of a consistent look and feel it was necessary to ignore the class attributes, managed by the FormElement::setClass() method. The existence of that method violates that separation between logic and presentation. It might be possible to whitelist a set of allowable classes, but to make that work across all themes, we would have to dictate our own intermediate set of semantic classes, and translate those in the renderer. Just to understand the scope of that effor, Bootstrap is now a version 4 of their semantics, and it is still evolving. The setClass() and getClass() methods are relics, and should have been marked a deprecated. They open a set of problems that cannot be fixed.

But, that doesn't mean all hope is gone. The solution to the missing setClass() is simple -- do it in the theme!

There should be a template where the form is displayed. Within that template, you can address each form element by its ID, so a script section can easily set any desired attribute, including class. Add a comment or two about why these are needed, and you make a template that others can easily adapt for any CSS framework. And it is all in the control of the theme, not some chunk of PHP code that needs to be hacked again and again over time.

It is just a growing pain.

Quote:
I would agree with Mamba's post

As to the deprecation of MyTextSanitizer, let me clearly state that it is still an important part of XOOPS, and is not deprecated. Most input needs are better handled with Xmf\Request now, but the text sanitizer is still with us and has a future. (It actually improves and grows in 2.6.)

A number of methods in MyTextSanitizer have been deprecated for quite some time. There is a comment line that marks the set of deprecated methods that are at the bottom of the class/module.textsanitizer.php file.

In 2.5.9 we did deprecate some of the extensions -- mms, wmp and rtsp -- that support media formats that are virtually extinct on the modern web. All of those got new options to disable editor buttons, even if the extensions are enabled. Flash got a similar treatment. If you have legacy content, the extensions should function as best they can. But creating new content with these is discouraged.

I hope that clears things up.