Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
Hi David,
I recently ported my Anti Spam Action to Wordpress using a custom short code that calls on a PHP function to mangle the entered email address. It works pretty well, if I say so myself, and was really easy to create. I’ll try a search now but if Perch allows the base CMS to be extended in a similar fashion there is a chance you could do the same there.
Regards,
Tim.
On 20 Dec 2013, at 16:07, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
I had the same problem a couple years ago and got the same response from the devs. Walter’s solution is better than the default filter answer. I just wish Perch offered an integrated solution.
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
Looking at that one page of code (and having only used Perch once, last year, so I’m certainly no expert on it), there’s a clear argument for a BYOF solution in Perch, where there is a callback function that you can hook into any of the content types. I did something like this in my new Mini Active Record library:
Here, the save() method is just a thin wrapper around save_without_callbacks(), and serves as an ordered means of accessing all of the callbacks that may need to modify the record before it is really saved to disk.
Walter
On Dec 20, 2013, at 11:53 AM, Todd wrote:
I had the same problem a couple years ago and got the same response from the devs. Walter’s solution is better than the default filter answer. I just wish Perch offered an integrated solution.
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
No, it’s an example of how Perch could extend their core application to provide hooks for third-party filters to modify the output before it is painted to the screen. For example, in mar, the validate() function performs a “lazy” lookup of all validations that have been added to the object (some may have been added just before the object is being saved) and then performs them in the order they were added. For another example, before_save() is an empty function in the base class, but any subclass can redefine that function to make it actually do something. So if you wanted to obscure all e-mail addresses before saving to the database, you could hook that function I wrote earlier into a before_save() function, and from that point on, all e-mails would be stored in encoded form. (Totally meaningless example, but I’m just trying to explain how callbacks work.)
Walter
On Dec 20, 2013, at 12:27 PM, Todd wrote:
Would this be used in conjunction with your obscure function in the Perch file /apps/content/PerchContentItem.class.php?
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
It’s how the FreewayTalk Web site works, in part. In that setting, email addresses are located and replaced with a single opaque string of text. This was just an extension of that technique to use the callback form of preg_replace, which lets us take the match string and convolve it through another function.
As I said earlier, I used Perch once last year, and recalled that it was pretty modular in its construction. It only took me three blind tries to find the right file to fiddle with.
Walter
On Dec 20, 2013, at 2:00 PM, David Owen wrote:
Hi Walt,
You came back with this quickly. Is this something you’ve tested yourself?
I tested the PHP code here in a tool called CodeRunner, which lets you live code in any language and then run that code in a REPL (read eval print loop) – a simple text terminal that shows the result of the operation.
Walter
On Dec 20, 2013, at 2:00 PM, David Owen wrote:
You came back with this quickly. Is this something you’ve tested yourself?
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
My version of Perch is from last year or early the year before that, so probably not up to date with the current application layout. I can’t find anything in the source code that indicates a version number – and I’ve looked through tens of files at random.
This approach looks possible, but from the documentation you linked to, it appears to be more suited to a single (and special) form field rather than the full body of the page, as my example provided. I would try to figure out what kind of field your page body is considered, and then duplicate that element as something like page_body_with_email_mask or something like that.
Walter
On Jan 8, 2014, at 8:11 AM, David Owen wrote:
Rather than hacking the Perch core I think you can add field types…
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
Mind you hacking the Perch core will void any kind of support. So I’ll need to wait till something is added or take an alternative route.
–
David Owen
On 8 Jan 2014, at 15:22, Walter Lee Davis email@hidden wrote:
My version of Perch is from last year or early the year before that, so probably not up to date with the current application layout. I can’t find anything in the source code that indicates a version number – and I’ve looked through tens of files at random.
This approach looks possible, but from the documentation you linked to, it appears to be more suited to a single (and special) form field rather than the full body of the page, as my example provided. I would try to figure out what kind of field your page body is considered, and then duplicate that element as something like page_body_with_email_mask or something like that.
Walter
On Jan 8, 2014, at 8:11 AM, David Owen wrote:
Rather than hacking the Perch core I think you can add field types…
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
Oh, well then you may be able to do things the way they suggest. My approach was a quick-n-dirty way to scan the entire page code (just before it is streamed to the browser) and encode anything that looked like an e-mail address into entities. If you were to create a custom e-mail field, and then you were always ever after going to display that field’s contents in a structured way, like maybe something like this:
Contact Name
email_address
phone_number
Then you could use the approach they outlined – that’s precisely what it is for.
Walter
On Jan 8, 2014, at 10:54 AM, David Owen wrote:
Yes it’s a form field.
Mind you hacking the Perch core will void any kind of support. So I’ll need to wait till something is added or take an alternative route.
On 8 Jan 2014, at 15:22, Walter Lee Davis email@hidden wrote:
My version of Perch is from last year or early the year before that, so probably not up to date with the current application layout. I can’t find anything in the source code that indicates a version number – and I’ve looked through tens of files at random.
This approach looks possible, but from the documentation you linked to, it appears to be more suited to a single (and special) form field rather than the full body of the page, as my example provided. I would try to figure out what kind of field your page body is considered, and then duplicate that element as something like page_body_with_email_mask or something like that.
Walter
On Jan 8, 2014, at 8:11 AM, David Owen wrote:
Rather than hacking the Perch core I think you can add field types…
This will obscure all e-mail addresses it finds into entities. It’s not a very sturdy solution to the problem, because I would guess that the nasty people have already got their de-entity filters warmed up and ready, but it at least looks like you tried.
Walter
On Dec 20, 2013, at 11:07 AM, David Owen wrote:
Using Perch CMS (it’s great by the way). There’s nothing out of the box to obscure email address using Textile and Markdown which I’d like to use because of simplicity. They suggest good email filters as the solution. Mmm… :-/
Any pointers or tips to obfuscate any email addresses entered in the CMS?
Yes, modifying the Perch Core is generally not a good idea, primarily because that’s how developers update the base code.
BTW, I saw your post on the Perch forum. Support is one of the biggest problems I have with Perch. I have no issues with Drew, but Rachel’s responses are often defensive, condescending, and sometimes just plain rude. She clearly knows how to develop amazing software, but she really needs to work on her CS skills.