Constants and 3.1

[nickvergessen]

In 3.1 we will have extensions and thereby loose track of the constants, as they are not going to be edited into the includes/constants.php anymore. This is not really a big problem in the most cases. However it comes to problems, when the values of said constants are used in phpBB. One example here is the log-system we have:

phpBB itself currently uses the following log cases:

Code: Select all

// Log types
define('LOG_ADMIN', 0);
define('LOG_MOD', 1);
define('LOG_CRITICAL', 2);
define('LOG_USERS', 3);

Taking the gallery as an example:
to add a new log case, you currently add a new constant to the file:

Code: Select all

define('LOG_GALLERY', 4);

and add a comment like

If the number 4 is already a Log of an other MOD, just use the next free number.

to the edit. This however does not work anymore, as edits should be omitted the user will not see it. Now, that alone will not break stuff. However, if you have another MOD, that uses the log system, you will get a conflict, as the number 4 is already taken.

There are two ways to circumvent this problem:

1. The MOD authors use "big" numbers, to avoid collisions. Randomly chosen this can still give you a conflict, when two MOD authors choose the same value.
2. We make a system (wiki) where its written which Constant is used for what. In this case there would be a section "logs" with a table for the constants, their name, author/extension and description:

   Code: Select all

   // Log types
   0   	LOG_ADMIN   	core
   1   	LOG_MOD     	core
   2   	LOG_CRITICAL	core
   3   	LOG_USERS   	core
   4-10	N/A         	core                 	Reserved
   11  	LOG_GALLERY 	nickvergessen/gallery	phpBB Gallery Log (images and albums)

   MOD authors could then apply for a key and would be given one.

What do you think about this?

[MichaelC]

Sounds good.

[brunoais]

I like it.

MOD authors should fight for their 99 available slots where they could use in all the MODs they do.
Phpbb has the ones that start with 0. Person A has the ones that start with 1... Person gaswdf has the ones that start with 423523.
Ex, for the earlier ones, each one has the "mask":
0xx, 1xx, 423523xx. Where xx are digits from 0 to 9.

Note: Yes, 99 is big, is an exaggeration, but a DB can easily store numbers in the 10^9 easily, that allows us to have 10^6 different MOD makers that mess up with the logging system. 10^6 is 1 Mega users. I don't believe that there are 1Mega coders in the world so... we're safe . So I think this is an even better approach and an improvement to your idea that will work for many ages.

1 problem... We won't be able to control MODs that do not come to phpbb.com's database. How do we solve with those? Ignore and assume that all is ok?

[nickvergessen]

1 problem... We won't be able to control MODs that do not come to phpbb.com's database. How do we solve with those? Ignore and assume that all is ok?

Well its the only thing we can do. If one has his constant range and another mod uses the same value he would not be accepted in the mod db. If one codes a wrong mod and users are having problems they will complain and than one of the authors will see what the problem is and either change his code or ask the other mod author to do so.

Btw this is also current behaviour in most cases were mods conflict/cooperate.

[igorw]

How about we scrap constants and just switch to strings?

[callumacrae]

How about we scrap constants and just switch to strings?

+1

[nickvergessen]

As for switching to string, this is not easily possible and will cause more work than it helps.

I went through the source and found the following cases which I think are affected:

• log-type, i personally know a mod that uses it
• user-type
• user-inactive-reason
• group-type
• forum-type, i personally know a mod that uses it
• item(topic) states (locked)
• forum-flags, should not be used by mods
• forum-options, should not be used by mods
• bbcode-options, should not be used by mods
• topic-types
• confirm-types
• attachment-categories
• profile-field-types
• user-option, should not be used by mods

[nickvergessen]

Okay, after a lot of IRC discussion the best result we found is to switch log_type from integer to string and use something like "nickvergessen.gallery" as identifier, and core.(admin|mod|critical|user) for the current core logs, similar to the ledge/hook names.

As for the other things I cant remember they are reused very often, also f.e. a conflict on forum-type is noted immediately after the extension is installed.

[MartinTruckenbrodt]

Hello nickvergessen,
I think the second of your original solutions although should work. It would be the same e.g. like for the TCP ports 0 - 1023. If a MOD author is not contacting you or the MOD team then it's a problem of the users of the not validated MOD and the MOD author.

I think the LOG thing is a very special example cause unnoticed conflicts will result in data mismatch in the LOG_TABLE.

I have two another examples for similar added constants in my Advanced Double Activation Pack which is adding and improving some missing core features.

Bye Martin

[imkingdavid]

Okay, after a lot of IRC discussion the best result we found is to switch log_type from integer to string and use something like "nickvergessen.gallery" as identifier, and core.(admin|mod|critical|user) for the current core logs, similar to the ledge/hook names.

As for the other things I cant remember they are reused very often, also f.e. a conflict on forum-type is noted immediately after the extension is installed.

+1 Sounds good to me.