Register and Memberpages

[cmb]

Hi Gert, hi Frank,

I've found, that both plugins are a bit sloppy regarding the detection of member pages. For Register_XH it's enough to have an arbitrary CMSimple Script on the page and the bare text "access(" to cause hiding the page (if hide_pages is set to 'true'). In Memberpages_XH 2.x that's basically the same. For Memberpages_XH 3.0-concept it's even enough to have the bare text "member(...)" on the page to make it a member page.

I suggest to check, if the member function is written as CMSimple scripting or plugin call. This might be done for Memberpages_XH 3 in the following way:

Code: Select all

//hide memberpages unless a member is logged in or it is edit or adm mode
if(!($edit && $adm))
{
//    if($plugin_cf['memberpages']['hide_pages'])
//    {
        for($i = 0; $i < $cl; $i++)
        {
            if(strpos($c[$i],'member('))
        {
                if (preg_match('!(?:#CMSimple |{{{PLUGIN:)member\((.*?)\);(?:#|}}})!i',$c[$i],$matches))
        {
            if(trim($matches[1],"\"'")) {
            $access_level = trim($matches[1],"\"'");
                    unset($_SESSION['page']);
            if($plugin_cf['memberpages']['exactmode']) {
                    if(!isset($_SESSION['accesslevel'])
                 || $_SESSION['accesslevel'] != $access_level)
                    {
                        $c[$i] = '#CMSimple hide#';
                    }

            } else {
                    if(!isset($_SESSION['accesslevel'])
                   || $_SESSION['accesslevel'] < $access_level)
                    {
                        $c[$i] = '#CMSimple hide#';
                    }
            }
            } else {
                if(!isset($_SESSION['accesslevel']))
                {
                    $c[$i] = '#CMSimple hide#';
                }
            }
        }
            }
        }
//    }
}
 

For Register registerRemoveHiddenPages() could be rewritten in a similar way.

IMHO it would be even better to set the access groups resp. level via a page tab, but that might not be the best idea as long as content.htm and pagedata.php are prone to desynchronization.

Christoph

[svasti]

Hi Christoph,
you'r right. I just wanted to make it easy and fast to use.

IMHO it would be even better to set the access groups resp. level via a page tab,

I also thought about that, but then I found that it is more visible to have the Command on the page. This way one can see right away that it is a member page. If it would be set in page tabs, one would have to go there first.

But your addition is very good idea, just tried it out, and I'll implement it ... together with some more enhancements.

svasti

[Gert]

Hello,

Carsten Heinelt has allowed me, to give the further development of Register_mod_XH to other hands.

@ Christoph and Svasti: Are you interested?

You should mention Carsten as auhor (as it is) and me as "XH modifier" in the backend (with link) and in the Core files,

Gert

[cmb]

Hi Gert,

I'm not uninterested in maintaining Register_mod_XH, but as I'm somewhat behind schedule with several other plugins, I would be glad, if someone else will do this.

Keeping the copyright notice and backlinks to Carsten and yourself is IMO quite natural. But what about changing the license to an open source license (e.g. GPL)? This would ensure the plugin could be maintained by someone else in the future, without explicitely getting permission from Carsten, yourself and the next maintainer. Might that be an option?

Christoph

[Gert]

But what about changing the license to an open source license (e.g. GPL)? This would ensure the plugin could be maintained by someone else in the future, without explicitely getting permission from Carsten, yourself and the next maintainer.

I'm sure, that Carsten is not interested in Register anymore, so it should not to be a problem. There is no license information in the sourcecode, and he has allowed me to give it to anyone for further development.

I'm not uninterested in maintaining Register_mod_XH, but as I'm somewhat behind schedule with several other plugins, I would be glad, if someone else will do this.

Under your care and guidance?

I also have own projects enough, and I will close the further development of the "modified for XH" plugins. If there will be not new maintainers of these "Community Plugins", I will archive them under the status "developement closed",

Gert

PS: The new maintainer can have a nice link from my website, like Svasti for Memberpages

http://www.ge-webdesign.de/cmsimpleplug ... erpages_XH

[cmb]

Hi Gert,

Under your care and guidance?

No, but if the maintainer asks me for help, I'll do my very best to provide it. Otherwise I'll keep my nose out of the further development, except for potential bug reports and suggestions. And of course anybody is invited to do so for my plugins.

The new maintainer can have a nice link from my website

A tempting "bribe"

Christoph

[cmb]

Hi Gert,

as nobody else responded to your offer to be the new maintainer of Register_mod_XH: I'm willing to take over the maintenance of the plugin. I have already mailed Carsten Heinelt asking for permission to change the license to GPL. If he won't reply, I'll probably stick with the freeware license.

Christoph

[Gert]

Hello Christoph,

I have published my current state of development as Register_mod_XH v1.3:

http://www.ge-webdesign.de/cmsimpleplug ... ter_mod_XH

Please tell me, when you have published your first version, then I will declare the closing of development and set the promised link,

Gert

PS: I would not allow the plugin call by hi_pd_scripting (pagedata), the plugin call of Register should be in the content.htm mandatory.

[cmb]

Hello Gert,

I've just downloaded 1.3 and have a look at it over the weekend. I'll see, if I'm able to publish a first version (only slight modifications) next week, and announce that here in the forum (I'll additionally inform you via PM).

I would not allow the plugin call by hi_pd_scripting (pagedata), the plugin call of Register should be in the content.htm mandatory.

Until the possible desynchronization issues with content/pagedata are resolved, I'll definitely stick with the CMSimple scripting/plugin call in the content. But I was not talking about hi_pd_scripting (this might be used nonetheless, if hi_pd_scripting is loaded before register, doesn't it? But indeed, if content and pagedata get out of sync, some "member pages" will become visible.). Instead I had in mind an own tab with a multi-selectbox or checkboxes for the defined access groups (would save some typing).

Christoph

[Gert]

But I was not talking about hi_pd_scripting (this might be used nonetheless, if hi_pd_scripting is loaded before register, doesn't it? ...)

I think, register is looking for the #CMSimple...# script on the page (in the content)

However, it's YOUR plugin now

Gert