This is probably due to https://github.com/Cockatrice/Cockatrice/pull/4607/commits/eb7b69c753b5b9889426af5c27c5f5c299eff986

I guess the definition of Servatrice::incTxBytes() should be moved inside "public slots"

Some characters are valid in URLs but not in cookies, eg. comma or semicolon. They needs to be encoded properly.

Correctly urlencode path in setcookie(); fix #3538

Some characters are valid in URLs but not in cookies, eg. comma or semicolon. They needs to be encoded properly.

I'm using Prado 4.2.1 and I can't use Php Traits. Is that normal? How can we use traits with Prado?

Make Prado::using able to autoload traits defined as prado3 namespaces (#876)

Fix #875

Memo: Prado::using can be made able to autoload enums, too (see #876 as an example)

Can you please test if https://github.com/pradosoft/prado/pull/876 fixes the error for you?

Fix #875

Made a simple test starting from the helloworld demo:

<?php

trait MyTrait
{
    public function sayHello() {
        return 'hello from trait';
    }
}

class Home extends TPage
{
	use MyTrait;

	public function buttonClicked($sender,$param)
	{
		$sender->Text = $this->sayHello();
	}
}

And the result is:

It's hard to answer without an example of what you are doing and the error you receive.

As far as i know traits are used to collect methods that are used in different classes, as a way to workaround php missing multiple inheritance. If you have a single form/page, you can't include a trait more than once in a single class.

Do you mind sharing an example of what you are trying to do? Traits are a php feature, i can't see a way prado can interfere with them.

The ReflectionClass calls definitely needs some type of caching to avoid creating possibly hundreds of identical objects for a single template

From a few quick tests and some literature found on the web it seems that creating ReflectionClass objects is only expensive the very first time, while following object gets created in a negligible time. Still, if this needs to be extended to methods introduced by behaviors, we need caching for our part.

Merged, thank you!

Fix #869

Remove execute permission on all files excepted on php-cli (#874)

• Remove execute permission except on php-cli

When installing Prado by composer, I see that a lot of files (.php, .tpl, .page, .xml, .sql, ...) has the exec permision. Is there any reason for that or is it a mistake on a previous commit?

Exemple: ... ./pradosoft/prado/tests/unit/Util/Behaviors/TBehaviorParameterLoaderTest.php ./pradosoft/prado/tests/unit/Util/Behaviors/TTimeZoneParameterBehaviorTest.php ./pradosoft/prado/tests/unit/Util/TLoggerTest.php ./pradosoft/prado/tests/unit/Shell/TShellWriterTest.php ./pradosoft/prado/tests/initdb_mysql.sql ./pradosoft/prado/tests/initdb_pgsql.sql ./pradosoft/prado/tests/test_tools/PradoGenericSelenium2Test.php ./pradosoft/prado/tests/test_tools/phpunit_bootstrap.php ./pradosoft/prado/tests/test_tools/README.txt ./pradosoft/prado/framework/Web/Javascripts/source/prado/activefileupload/ActiveFileUploadError.png ./pradosoft/prado/framework/Web/Javascripts/source/prado/activefileupload/ActiveFileUploadComplete.png ./pradosoft/prado/framework/Web/Javascripts/source/prado/activefileupload/activefileupload.js ./pradosoft/prado/framework/Web/Javascripts/source/prado/activefileupload/ActiveFileUploadIndicator.gif ...

Normaly, only ./pradosoft/prado/bin/prado-cli should have it, right?

Implement a new parameter in THttpRequest to modify the behavior used to determine the correct service to be used to handle the request (#871)

An PRADO application can expose multiple services; usually there's a single "page "service, but more can be defined in application.xml. The way PRADO detects which service to run is implemented in THttpRequest: https://github.com/pradosoft/prado/blob/master/framework/Web/THttpRequest.php#L761 This looks a bit fragile.

I have an example application containing 2 services: a "page" service hosting a website and a "geonode" service, accessed by desktop applications like QGIS. Requests to the "page" service runs fine with urls like http://127.0.0.1/prado-app/page,Home. Requests to the "geonode" service are a bit more complex and contains parameters hardcoded in the client, eg: http://127.0.0.1/prado-app/geonode/api/v2/layers/?page=1&page_size=10&sort[]=name&filter%7BstoreType.in%7D=dataStore&filter%7BstoreType.in%7D=coverageStore A problem arises on the second request: Prado merges all the request parameters in a single array, and loops through the array to look for a service id. The "page=1" parameter gets interpreted as a request to the "page" service, and since it's the first service matching in the array it gets used, even if it's not the correct one. Now, since the request parameters are hardcoded in the client (https://github.com/GeoNode/QGISGeoNodePlugin/blob/main/src/qgis_geonode/apiclient/geonode_v3.py#L56), i can't really fix them but i need a way to workaround the problem, forcing PRADO to use the correct service.

I'll try to workaound this in my app overloading the THttpRequest::resolveRequest() method, hopefully finding a way extract all matching services and giving priority to the one appearing first. If you have any comment on other ways to fix this, i'd be glad to hear from you :)

This new parameter instructs THttpRequest on the behavior used to determine the correct service to be used to handle the request Fix #868

Defaut permission for files and directories (#873)

• Set the cache path of HTML Purifier in the runtime instead of the root path in vendor directory
• isolate the htmlpurifier in a specific directory
• Change the exception message
• Fix TConfigurationException use
• Add new functions for file et dir to get the permissions
• Get the define of PRADO_CHMOD if defined for the two new CONST
• Update history and upgrade file
• Update UPGRADE.md

Merge branch 'master' into fix_868

Hi,

Is there any particular reason to have set the default permissions to 0777 for the PRADO_CHMOD constant? I think that for security reasons it would be better to have the value at 0755.

Shouldn't there be two constants, one for files at 0644 (PRADO_FILE_CHMOD) and one for directories (PRADO_DIR_CHMOD) at 0755? There is no reason to put execution rights on files.

Jean-Luc

Defaut permission for files and directories (#873)

• Set the cache path of HTML Purifier in the runtime instead of the root path in vendor directory
• isolate the htmlpurifier in a specific directory
• Change the exception message
• Fix TConfigurationException use
• Add new functions for file et dir to get the permissions
• Get the define of PRADO_CHMOD if defined for the two new CONST
• Update history and upgrade file
• Update UPGRADE.md

Two new functions was added as proposed by @ctrlaltca Prado::getDefaultDirPermissions() and Prado::getDefaultFilePermissions(). The function Prado::getDefaultPermissions is now deprecated.

The const PRADO_CHMOD is also deprecated and must be replace (if required) by PRADO_DIR_CHMOD and PRADO_FILE_CHMOD. For backward compatibility, until the next major release, the define PRADO_CHMOD has priority if defined in the index.php.

Fix #865

In version 8.1 php added official support from enums. Prado makes extensive use of TEnumerable to fake enums. Switching to native enums could make the code less weird to new developers and static analyzers. I know it's too early to require php 8.1, so the change should be backwards compatible for the time being.