getRequestedPage and custom attributes

Permalink
I am trying to modify the addon automatic email obfuscator.
In the controller we can find this code that I'm trying to modify.
public function on_start() {
$req = Request :: get();
$p = $req->getRequestedPage();
if (!$p->isAdminArea()) {...


As you can see, the code is set to work on every page requested except the dashboard.

What I want to do is add an exception to it.
One of my pages has a custom attribute.
I would like that page to also be ignored so the emails on it are not obfuscated.

I tried:
if (!$p->isAdminArea() || !$p->getAttribute('my_attribute'))

I also tried:
if (!$p->isAdminArea() || !$p->getCollectionAttributeValue('my_attribute'))

Nothing works. It's as if , on page request, custom attributes were ignored.

Any help would be more than welcome
Thank you.

mnakalay
 
Mainio replied on at Permalink Best Answer Reply
Mainio
Hi,

Since we have created that add-on, it might be also good for us to answer this one. :)

You first method is 100% correct, the problem is in the $req->getRequestedPage() method that does not load the page attributes.

We might look into this at some point but quick fix for this is here:
$p = $req->getRequestedPage();
$p = Page::getByID($p->getCollectionID());


You might still want to use the $req->getRequestedPage() method above because it has some caching functionality so you don't have to find the cID always from the DB. Also, we don't want this add-on to add too much extra load in the loading process.

Br,
Antti / Mainio


EDIT: However, you need to set the or-operator (||) to and-operator (&&).
mnakalay replied on at Permalink Reply
mnakalay
Hi,

Thank you for your message it solved my problem. Actually it solved 2 problems in one.
And thanks for that || && comment, that was silly of me :)

There is still one little thing I'm not sure I understand.

You said might still want to use the $req->getRequestedPage() method because it has some caching functionality.

So if I understand well I have to choose either
$p = $req->getRequestedPage();

or
$p = Page::getByID($p->getCollectionID());


What I understand is that the first one is lighter on the system because of its caching functionality but then I can't do what I want and the second one allows me to do what I want but is heavier on the system. Am I correct or am I missing something??
Mainio replied on at Permalink Reply
Mainio
Hi,

Actually it was just some running thought of mine.

Page::getByID() has also some caching functionality, so it shouldn't be so much more load when those two functions are used together. However, it seems a bit silly to first get the page in one method and then with another, that was what I was pointing at.

At that point when the on_start() method is called, there is not yet the global $c variable available. Therefore, it needs to be get in some other way. The Request::getRequestedPage() just resolves the requested path and gets the right view accordingly, so basically that's why it is used.

I'm not sure but this might also work (has not been tested):
$p = $req->getRequestedPage();
$p->loadVersionObject();


If that works, it wouldn't seem so silly to get the same object twice in a row. Basically the question here is nothing more that code conventions and "best practices". Most of those methods have caching in them, so you shouldn't worry about that too much.

Br,
Antti
mnakalay replied on at Permalink Reply
mnakalay
Thank you very much for your help.

By the way, I wrote some encryption code for your addon. It's based on the vigenere cipher so for email obfuscation I think it's quite secure. I don't know if anybody would be interested or not. I can't offer it as an addon since it's not really an addon.
If you want to have a look, maybe offer it with your addon, let me know, i'll send it to you.
I'm planning on writing a little tutorial about it as well so I suppose I could also put it there for download.

Thanks again
Mainio replied on at Permalink Reply
Mainio
>> By the way, I wrote some encryption code for your addon. It's based on the vigenere cipher so for email obfuscation I think it's quite secure.

If you have licensed it with MIT, I would love to take a look and see if it can be added to the add-on! If you have some other licence, you can create an add-on for it to the marketplace.

However, please still note that this add-on is NOT under the MIT licence so please be sure to inform in those files clearly that it's under MIT.


Br,
Antti
mnakalay replied on at Permalink Reply
mnakalay
Thanks for your interest.

For some reason I can't seem to be able to attach files so I'm sending them to you by PM.

It is an extremely paranoid encryption for email obfuscation but spammers are really a pain.

One thing: I use very descriptive variable names. I know it's not very professional looking but helps me not get confused.

Let me know what you think.