Update to the MODDB policy for phpBB3.

[Paul]

Hi Paul,

Still no guidelines on language imageset files. Seems this file type is often forgotten.

No, its still on my list to write a policy on . I hope it will follow this holiday, but iam pretty busy.

[Paul]

Hi all,

as preperation to publish more policies to the public we have moved our general MODDB policy to http://www.phpBB.com/mods/policies/general.php
Within the upcoming week, a new set of policies will be publised, wich are already used at validation.
All links in this topic have been updated to this new location.

the phpBB MOD team.

[crazygandalf]

I read a licence and there is one thing that it doesn't cover.
Any mod I make must be GPL2 or compatible. That's clear. But what if I include some 3rd party code that uses their own license that is e.g. free use for non commercial sites.

[tumba25]

Anything you include must have a license that is compatible with Gnu GPL v2.

[Paul]

Hi all,

We have updated our MODDB policies regarding Insta-Deny to extend the requirements for Insta-Deny and the timeframe Insta-Deny can happen. You can find our newest Insta-Deny policy on this page: http://www.phpbb.com/mods/rules-and-pol ... nsta-deny/

If you have any suggestions or questions, please ask them in this topic.

the phpBB MODifications team.

[Unimatrix_0]

Hi,

I thought about build up a new skin for phpBB3 first for my own use but I had also in mind to publish it later on, but within this thoughts I realised that it would cause minimum double work to make the skin working for me and then remove all skin-parts that are caused by mods to reduce it to the standart-design. So I had the idea that it would be greate if every modification that need changes on any template file would have to add template-variable (f.e. S_MODNAME_INSTALLED) in the functions.php (this would be the best place i guess for a simple overall use) so skinners could just use the

Code: Select all

<!-- IF S_MODNAME_INSTALLED -->
Output the new cool skin stuff
<!-- ENDIF -->

and prepare skins by default for modification. This could also raise the mod-compatibility for highly modified skins that not really have any base with prosilver or subsilver.

The second thought about this was to use the config-value for the installed mod-version (from UMIL) to define this template-var. This should be easy for the most modifications and would allow more prepared skins

just a simple idea ... I hope you like it.

Best regards Un1

[battye]

After consultation with the community (http://www.phpbb.com/community/viewtopi ... &t=2119712) the MOD Team would like to inform the community of several new policies which have been implemented:

http://www.phpbb.com/mods/rules-and-pol ... b/general/

Externally hosted scripts
Please be aware that MODs referencing external sources (such as externally hosted Javascript files) will not be accepted into the MOD Database. Any files required by the MOD should be packaged with the MOD.

phpBB3 or MODX updates
MOD authors may re-submit their MODs for validation if the only changes are either:

• Updating the version of MODX used by the modification and the phpBB version which the MOD applies to.
• The phpBB version which the MOD applies to.

MODs re-submitted on this basis will still be reviewed and tested on the latest version of phpBB. Re-submissions reflecting a new MODX version alone will not be accepted.

Thank you to everyone who gave input,

MOD Team

[Paul]

Hi all,

The MOD team has updated the phpBB3 MODDB policy, with the next change:

• It is now required to have all filenames, table names, comment names etc. in English. Any other language it not longer allowed.
• All included 3rd party libaries should be the latest version of that libary at the moment of submission of the MOD.
• It is now required to increase your version number on a new submission.

The updated policy can be found at http://www.phpbb.com/mods/rules-and-pol ... b/general/ All submitted MODs from this moment are required to follow the updated policy, and will be denied if they dont meet the requirements.

Thanks,
The phpBB.com MODifications team.

[Paul]

Hi all,

We have updated our MODDB policies with a new rule regarding sending data (Like posts, or other user information) to remove information.

You can find the updated policiy here: http://www.phpbb.com/mods/rules-and-pol ... l/#privacy

Thanks,
The phpBB MODifications team

[darksminky]

I hope this hasn't already been mentioned, but the policy surrounding request_var is ridiculous. isset and empty can handle a function if its output is put in a variable, and allowing issets and empties to deal with the request var straight up completely defeats the point, as (or at least I thought) the idea behind request_var is to allow for more versatility in the Style, as a form's method can be changed without having to update all of that. And yes, the type casting still applies, but that's not what request_var is for, is it?

Code: Select all

$workaround = request_var('submit_foo','bar');
if(isset($workaround))
{
//bl abla bola labla  lbabla blabla blab bla bla bla
}

the passage I refer to:

To retrieve a value from $_POST/$_GET you should always use phpBB3's request_var function. You should not access $_POST/$_GET directly. An exception is checking whether a variable is set, such as isset($_POST['submit']).

[primehalo]

This is pointless:

Code: Select all

$workaround = request_var('submit_foo','bar');
if(isset($workaround))
{
//bl abla bola labla  lbabla blabla blab bla bla bla
}

This is how you would do something like that:

Code: Select all

if(isset($_GET['submit_foo']) || isset($_POST['submit_foo']))
{
    $workaround = request_var('submit_foo','bar');
    //bl abla bola labla  lbabla blabla blab bla bla bla
}

[Paul]

request_var is meant for type casting and having one method for request all user input. It is not ment as replacement for isset, and your example would always return true with isset, as the variable is set.

[darksminky]

maybe for isset, but for empty most would work (default is usually '' or 0 ) and anyways, using

Code: Select all

$SUPERGLOBAL || $SUPERGLOBAL

defeats the point of having one function to nab both simultaneously, and while you can throw out an or statement like that, I see a number of MODS in MODDB that shamelessly use $_POST outside of issets instead of request_var also, Functions.php openly states that type casting isn't the primary purpose. Fetching is.

/**
* request_var
*
* Used to get passed variable
*/

Code: Select all

if(request_var('foo','bar') <> 'bar')
{
//stuff
}

instead of

Code: Select all

if(isset($_GET['submit_foo']) || isset($_POST['submit_foo']))
{
    $workaround = request_var('submit_foo','bar');
    //bl abla bola labla  lbabla blabla blab bla bla bla
}

EDIT: I do see your point about isset, but it is used 5 times inside of request_var, testing its default output to something that would be entered does the same thing as isset'ing the two superglobals.

[primehalo]

Testing whether the variable exists is not the same as testing for the default value you give it:

Code: Select all

if (isset($_GET['foo']) || isset($_POST['foo']))
{
    $foo = request_var('foo', 'bar');
    if ($foo != 'bar')
    {
        echo '$foo is not my default value so take action A.';
    }
    else
    {
        echo '$foo is my default value so take action B.';
   }
}
else
{
    echo '$foo is not set so take action C.';
}

[darksminky]

as seen here, it is in fact, the same thing:

Code: Select all

if (!isset($_GET[$var_name]) && !isset($_POST[$var_name]))
		{
			return (is_array($default)) ? array() : $default;
		}

unless I've misunderstood, that's just saying if it's not a set, return default.
thus, testing for default matches and testing for a set are one and the same. . .
EDIT:
just out of curiosity, is there a reason to prefer <> or != over the other?
I've always used <> as a habit from learning SQL first