Keep your admin interface CSS separate from the rest of your CSS.

There are a number of reasons to do this:

• Security: In CSS, a number of class names and IDs are revealed. And, if you’re programming your code semantically, they should be pretty explanatory (see: verbose). This exposes the names/interfaces/code structure and featureset of your administration interface to anyone who can look at the CSS. Not Good.
• Extra space / slows down the interwebs: Let’s face it, more than 99% of your userbase should be normal users, right? Why add on all this extra CSS just for the 1% of users. Keep it trim and fitting the 99% of users. This is 19% better than Pareto’s principle even!
• Another HTTP request for admin is fine… Usually when you’re logged into the administration side of things, you’re not expecting lightning fast results anyways. And to top it off, you’re no longer (and never were) a conversion. Speed and usability matters much more for your conversion statistics (IE, this user may leave because the site is too slow). You’re not going to abandon your own site because your admin interface is too slow, are you? (True, though, that’s not me just giving you free-for-all to make horribly slow admin interfaces though…)

Keep your Admin Interface CSS Separate is a post from: Aaron Saray

1

Now, the entire object was an empty mock. I had to define each one.

Define your methods to mock only, instead.

Try this:

1

Oh, and to make it easier, in PHP Unit 3.6, it’s all built in as a second parameter of the getMock() call:

1

Sweet.

PHPUnit Mock Objects: Only Mock What You Need is a post from: Aaron Saray

Enter Zend_Translate! Here is what I suggest:

Create a Zend Translate instance for your entire project. Store this in the Zend_Registry (I tend to do this in the bootstrap because every item, whether it be CLI or web, needs the ability to translate output). Then, create your situation where you might have to add an error message. Finally, translate the message before it is added to the persistent storage.

Side note: There is some argument as to whether the translation should be handled in the controller or when you are trying to show the view. In this example I will just be showing / suggesting in the controller. However, that is a good discussion to have… perhaps this should only happen in the views…

Let’s check out some code in an action

1
2
3
4
5
6
7
8
9
10
11

It may be easy to forget that we want to translate all of our output. Don’t forget the error messages in the controller!

Translate Your Error Messages in Your Zend Framework Controllers is a post from: Aaron Saray

Technology/Process:

thebetterbachelor.com was redirected to /10dish for 10 Dish Cookbook. The thought was at some point to broaden the platform if the cookbook was successful.

This was a one page selling page with a paypal link. It simply talked about the features of the book, the cost of creating your own meals, and compared this all to going out. The cost savings was emphasized.

I also appeared to give an ‘author’s note’ to the potential customer.

If the visitor chose to purchase, it was a paypal IPN process. So they received a success message and then they were emailed a link to download the PDF when paypal finished the transaction. The link contained a special URL that used Zend Framework to read in the source PDF and stamp their name and email on each page.

There was also a coupon system that bypassed the purchase system and allowed an instant copy to be sent.

Lessons Learned

I learned that I really needed to give away a free chapter. Up until receiving the product, visitors did not know the quality of the book. It could have been horrible with no pictures.

After speaking with a SEO expert I know, he set me up with an A/B test. Unfortunately, not a lot was determined from that. His suggestions was to develop the newsletter style approach which seems to work. Hook people for some free information, and make a sales pitch later. I never thought of doing this because when I purchase something myself, I want it. I don’t want to wait till I get a few emails about it first. But, he says this seems to be the best way to market items like this.

Overall, it was a good project. I didn’t sell as many as I’d like but I paid for the cost of the food – and that was enough for me!

Screenshots:

Bonus! Download the cookbook free! 10dish Cookbook

Site profile: thebetterbachelor.com is a post from: Aaron Saray

Aaron Saray

Today we are comparing Filters and Validators. Generally, we filter data to remove unwanted parts. Validators are used against data to validate that it meets certain requirements. As you see, these have some overlap, and it all depends on how you might choose to implement them. You could validate that a string is only alpha-numeric (and subsequently reject it if it is not), or you could filter out non-alpha-numeric content and accept that as your data.

So the questions are related to the following thoughts. Feel free to share your experience and best practice advice. Should you filter your data before you store it? Should you filter for harmful web content, harmful xml content, or business requirements? How do you determine what is ‘harmful?’ Would you say there is a difference between filtering input and filtering output? What about when you validate based on business rules? What if the rules change and you now have filtered or validated data this no longer valid? Could you do a conversion if you kept all data and didn’t filter it out permanently?

Joel Clermont

Quote: …Should you filter your data before you store it? … I’m a strong believer in the basic principle: filter input, escape output. Both are equally important. If you do this properly, you can probably avoid 3 or 4 of the top 10 exploits listed by OWASP.

Quote: … Should you filter for harmful web content, harmful xml content, or business requirements? … I guess it depends on the definition of the word “harmful”. I tend to think of things that could either harm the system (SQL injection) or harm the system’s users (XSS, malware links, etc). Some people might extend that to be harmful to the company’s reputation (graphic images or language).

My main advice here is to not reinvent the wheel. There are some great libraries (HTML Purifier, for one) that handle this. Oh, and don’t think that PHP’s strip_tags or ZF’s Zend_Filter_StripTags are up to the task. They’re not.

Quote: … Would you say there is a difference between filtering input and filtering output? … Filtering input is about protecting the system. Escaping output is about protecting the user. Both important, but they are implemented separately and solve different problems.

Quote: …Could you do a conversion if you kept all data and didn’t filter it out permanently?… This is a tough one. Some filters, like stripping whitespace, would likely never change. They will always be in play. But maybe if you normalize data (state/country names, for example), there’s no way to de-normalize that in the future and get raw customer input. I guess if I thought I would ever care about the raw data, I might store that somewhere else for posterity’s sake. This seems like an edge case however.

James Rodenkirch

Interesting topic, and actually very timely with projects I am dealing with on a daily basis

Currently we are building out an enterprise level data warehouse for education data and one for corrections data. As surprising as this may seem to some, both of these domains have HORRENDOUS data. We see instances of missing data fields, flat out wrong demographics, and data files that change from year to year.

Your question “Should you filter data before you store it?” – absolutely. You never want to store data that could come back and bite you in the ass. The concepts of data warehousing require that your data is stored in a pristine state, if it is not pristine, you hold it in limbo until it can be made pristine (usually requiring user intervention).

So, what if you are not running a data warehouse but are running a CMS? I would still strongly argue that it is important to cleanse/reject bad data before it gets stored. If you think about the read/write actions needed on the database you can quickly see that it is better to run filters/validators once on “write”, than every time the data is requested on “read”. Basic performance benefits lead us to doing as much of the filter/validation up front as possible.

Please note, this does not replace the need for escaping output on display – we always need to protect our applications and our users from dangerous data.

Jeremy Dee

Great points James. I’d like to add that while providers of web services (SOAP & REST) probably do a pretty good job of filtering & validating the requests they receive, I think that consumers tend to place too much faith in said services – probably giving them less filtering & validation than they should, especially with the easy deployment/proliferation of REST services. While many devs are quick to filter their form data, do they take the time to make sure that the current weather forecast they’re getting doesn’t have something nasty contained in it? Exception/Error handling around any type of XML parsing to catch unannounced changes response format isn’t a bad idea either.

In the case of critical web services, I often store a compressed copy of my request and their response alongside the data I’ve pulled out of the transaction for the flexibility it offers (maybe I’ll use more of this transaction’s data someday) and liability concerns.

Finally, a question I have for the group – what practices do you follow regarding “internal” filtering and validating on a big system. With high cohesion you get an explosion of objects, each with public methods potentially being called from anywhere. When do you check parameter types and/or values? Or do you just let it fail? Type hinting’s fine for objects, but what about primitives? Personally, I know some of my “gateway” methods that start a cascade of actions, so I’ll make sure that I’ve at least got my parameters straight before I proceed with them so I don’t have to do a giant rollback way down the call stack, but I’ve often wondered if it’s overkill.

Aaron Saray I have two thoughts. First, we always talk about escaping output when it comes to the user. However, there always seems to be a bit of confusion when the actual escaping should happen. Don’t you indeed escape potentially unsafe data going to your database (see: mysql_real_escape_string()) but you also escape it going outwards (htmlentities, etc)… So the question is where do you draw the line with escaping? Could one argue that you could do htmlentities before you store the data too?

Jeremy – in regards to your primitive checking. I’ve never come across a good standard for doing that checking. However, I’ve been known to write special methods per class… something like “_checkSanity()” with enough domain knowledge and type knowledge to filter out unwanted data. I’m sure that’s not the best way to do it, however. I generally would trigger a failure than to filter the content.

Eric Lightbody

I’d like to address the recent question that Aaron had in regards to where to draw the line with escaping. As a general rule I like to escape before it could be potentially harmful. If I’m going to store information in a database I need to make sure that the data going into it is safe. HTML entities are safe for a database, so I’ll let it be stored there. However, those same entities can be harmful for a browser. So, before I “store” it in the browser, I need to make sure that it is safe to be there. Business logic may change, and you may need access to the entities that were stored in the database.

As a side note, I would like to add that it is important that you make it easy on yourself for this type of work. Zend Framework, for example, provides a boatload of filters and validators. It also makes it easy to implement your own. If there isn’t a good structure in place to use the proper filters and validators, it’s easy to be lazy and let things slip through.

Jeremy Dee

Wow – great way of putting it Eric – “storing in the browser” – that notion of safely storing your data whatever that may mean makes for a nice rule-of-thumb.

Final Thoughts

I thought I’d publish this conversation so that other’s could see how a few professionals approach filtering and validating too. Any thoughts? Feel free to add comments below.

Filtering and Validating Discussion is a post from: Aaron Saray

Technology used: Zend framework command line cron job. Once an hour it ran. Pretty simple using the Zend Framework OAuth stuff. (Originally I was using the first version of the API to twitter – so I used standard HTTP requests).

Lessons learned: -Stay current when APIs change. I ignored the oAuth change at twitter and had a bot that was not functioning for a long time. -Follow the people you mention. Very little people followed the bot even though they were mentioned. -Lots of replies … ok so that isn’t such a ‘lessons learned’ but a “what should I have done about that” -monetization. What if I had grown a large collection of followers. Now what? -Personal account: I should have followed people that replied to the bot. I generally ignored all the tweets even. Pay more attention!

screenshots

Service profile: mketweeps is a post from: Aaron Saray

Goal: In 2001, having an online diary was only being piloted by a few people. Blogging was big, but considering it a ‘diary’ was not that popular. Only a few competitors existed: myopendiary and teendiary. I started my own online diary system for my own site. After a year, a few friends saw what I was doing and asked if they could do it too. I decided to launch JEMDiary for the three girls who wanted it as a free online diary system for all.

What happened: This was my longest running website. I think it was slightly before its time. When it became more popular, I just didn’t have the time to keep developing on it. Then, other larger sites eclipsed it and it slowly lost market share.

Technology: This was originally written in procedural PHP4. Then, later I migrated to PHP5 in procedural style. It finally became my first object oriented framework with my own custom controllers and views.

I used to host on dreamhost. Because of that, I learned what it was like to have a slow host that needed the site to be optimized more. I started compressing and caching my assets. I even ran a system to create the home page every hour as a static page with no PHP required. This made a huge performance boost.

I made lots of mistakes. One of the mistakes I made was to put the incompatible browser message at the top of the page. Then, almost all of my pages in Google showed up with that headline instead of their actual content. Whoops! (That was many years ago). To fix that, I made the tagline a h2 at the top of the page, but in smaller font. (the design of the page wasn’t such that large headings were that available all the time).

The other mistake I made was having the incompatible browser be a whitelist. So now, even with chrome, it gives a warning about having an incompatible browser. That is not the case.

The site went through 5 programming versions of which 3 of those had design changes as well. The last design was nice and clean and seemed to have the best conversion rate.

I did put in a few little easter eggs here and there too. Once someone was looking at the security of my site and sent me an email with one of the easter eggs they found. They thought it was clever. (I had put a header in there talking about the girl who I was in love with.) I also had a ‘boss key’ which allowed you to quickly replace the entire screen with any other url. By default I suggested a google search of ‘productivity tools.’

The final thing I did, which was really a big deal for the time, was to allow users to export their diary in both text and word doc format. In word doc, I would actually insert the images into their diary. The user had control of their data.

I learned from MySpace success for a time with the initial Tom friend. I would add myself as a friend. I also started using an automated system that would comment as my user on all new user’s content. It would make one comment on their profile and one on their first diary entry. I twas ran every few hours. The system would look at their account and create a special message based on things they said. For example, I suggested someone add a profile picture in 4 different ways. The system would pick one randomly – and only add it to the message if they didn’t have a profile picture already. A lot of the users thought I was actually adding the messages myself. (A few times the programming was faulty – and I commented on ‘deleted’ diary entries – that wasn’t good!)

Lessons learned: - keep with the times! I think I could have made some more money off of google ads if I would have kept current - use google ads and other ads! I wasn’t placing ads very well for a while. - advertise. I was still #3 in free online diary search on google – but sometimes people just didn’t search that. - some of my features were too advanced. Some people couldn’t tell the difference between password protecting your entire diary with the other feature to password protect only certain ones. - better anti-spam measures. I didn’t use a captcha or anything like that to sign up. After a while, I had a lot of spam entries.

Final thoughts: It’s almost sad to see something you’ve spent more than a decade with go away. But it was time to retire this beast. I’m so glad I made it, stuck with it, and that I get to pull the plug myself.

Screenshots

Site profile: jemdiary.com is a post from: Aaron Saray

Before we begin, it’s important to know the goal. The goal is to create a version of Zend_Mail that can read in views for both HTML and Text emails. In addition, since I am such a Unit Testing Fool, I want to make sure my new changes are testable. For once, you’re going to see a fully documented class! I’ll post the code here and then review it afterward.

application/models/Mail.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

Starting out the class, you’ll see I created it as a single class in a single file. The first two docblocks just define what this file does and what the class goal is. Next, the model extends the Zend_Mail class. For the most part, all of the features are perfect in the Zend_Mail class for our goal.

The two constants defined next will be used when determining the type of email body we’re currently working with. The constant name makes it easy to determine what the constant is for. The value is a normalized version of the ‘name’ of our view or layout that we’ll be using later on. It is important to note that views used later will be suffixed by the content of these constants. For example, the layout for text emails will be called emailtext because ‘text’ is the constant value.

The constructor defines the default charset. Since all of my views are UTF-8, I felt it necessary to define this by default.

I’m going to skip the setBody() method and talk about the other two methods real quick. You’ll notice that there are two methods called _getLayoutPath() and _getViewPath(). The reason these are methods unto themselves is to make this class easier for testing. Since you generally don’t define a test suite inside of an application (view files aren’t testable code generally), the user input for this would always be randomly or non existent. For our test suite, we can mock these two methods to point to locations where we keep assets for our tests so that we know the content of those files specifically. An additional reason to use this is if you introduce themes into your Zend Framework project. You may need to extend this class again to define where the theme’s view files are located (because they may not be in the default location).

Finally, the setBody() call. If you recall, the Zend_Mail class has both setBodyText and setBodyHtml methods. Once again, we see the constant values defined earlier coming into more use. This is more of a generic call because most of our code used to define the views is duplicate. Let’s dissect:

First, create a new Zend_Layout object (this is of course assuming your project is using Layouts. Let’s be honest, you more than likely are…). Then, depending on the type that is passed into the setBody() command, it sets the layout as emailtext or emailhtml. If neither type, it will throw an exception.

Next, create a new Zend_View instance. This will retrieve the script from the $scriptname parameter combined with the view location defined in the _getViewPath() method. Once this is created, each of the final parameter (the $params array) is applied to the view. This is what is used to populate your view once rendered.

Finally, the views and layouts are rendered and applied. The setBody specific command is called then of the parent class with our rendered view-based content sent in as a parameter.

This is how you might use this:

1
2
3
4
5

This would load the layout from APPLICATION_PATH/layouts/scripts/emailtext.phtml and APPLICATION_PATH/layouts/scripts/emailhtml.phtml. Then, the views would be rendered from APPLICATION_PATH/views/scripts/email.forgotpasswordhtml.phtml and APPLICATION_PATH/views/scripts/email.forgotpasswordtext.phtml

Extend Zend_Mail to use Views is a post from: Aaron Saray

The goal was to make a “hello my name is” style name tag without the use of images but with a handwritten font.

Trouble I ran into: nametag.me was already taken. I had to use the dashed version because I couldn’t think of a different name. hellomynameis.com was also taken. This became a problem because repeat visitors and word-of-mouth tend to forget about the dash. Plus, it is a lot harder to say: “name dash tag dot me.” I also found out that the .me name, although popular, was still hard for people to remember. A lot of .com visitors I’m sure.

Technical specifications: Open Graph integration. This is the first time that I used an apple-touch icon and an open graph image. Since the only images on the site were my signature portion (and link to my main website) and share icons, that was the preview that showed up when you shared it on Facebook. I added the meta property of og:image which pointed to the image.

1

Mod_expires / mod_deflate

I also used mod_expires and mod_deflate to compress and cache images/css/javascript out for a year. I also turned off ETags as I find that pretty annoying. Here are entries from the apache config:

SetOutputFilter DEFLATE

ExpiresActive On

ExpiresByType image/png A31536000
ExpiresByType image/x-icon A31536000
ExpiresByType application/x-icon A31536000
ExpiresByType application/javascript A31536000
ExpiresByType application/x-javascript A31536000
ExpiresByType text/css A31536000

#turn off etags
FileETag none

Because of this too, I decided to ‘version’ my css and javascript files. At the time of writing, I had version 3 of css and version 2 of javascript. Some people will add parameters at the end of the URLs but other caches/proxies can’t handle that properly. So, I decided to actually just change the name of the file itself. 3.css and 2.js, say hello to the world!

Browser sniffing body tag. Because there were specific layout elements in place here (and they had to work exactly), I had to sniff browsers. I did that with this famous line:

1
2
3
4
5

This was important because some browsers made the name tag misshapen so I had to change their CSS.

Whitespace What I didn’t do here was remove whitespace from my HTML and CSS. I have done that on other projects, but I just didn’t do that on this one. It was only 1.21k (2.02k deflated).

Clipboard Integration I ended up using a script called ZeroClipboard. This was a javascript that worked cross browser using technologies like the built in clipboard access to flash objects to send the URL to the clipboard.

jQuery Yup, used the google CDN.

Rounded corners In order to get rounded corners, but with all browsers covered, I used jQuery Corners plugin. I really wanted to use CSS border-radius but I also wanted this to work in IE… oh well.

TTF Font I defined the font I wanted to use using a utility called FontSquirrel:

1
2
3
4
5
6
7

Then later, defiend it in the font-family declaration:

1

Image Download I was able to use the same ttf font in my image downloading. I used imagettftext to position the items. I then sent the following headers:

1
2
3
4
5

Lessons Learned - Branding is important with the URL. I think a lot of people didn’t get the dash in the name. - Offering too much help, like click to copy to clipboard, is not worth it (Google analytics says that hardly anyone clicked that). - Average time on site was under 5 seconds. It’s unclear if people could use the functionality that quickly or if they just didn’t understand it and bounced. I should have made action funnels on actually filling in the box. - Check your userbase. Turns out, I didn’t need to use jquery corners (of course I wouldn’t know that till now). 1% of my visitors were Internet Explorer over the lifetime of the site.

RIP Name-Tag.me!

Screenshots / Downloads

Site Profile: name-tag.me is a post from: Aaron Saray

1
2
3
4

But, you’ll notice you have both a DT and a DD from the standard view helpers of HtmlTag. But, the DT usually contains the label attribute. In this case, the label element is part of the input now. It stead of being silly and using CSS to hide that empty DT, let’s just get rid of it… add the following to your code:

1
2

Simply, get the submit button you just added (you could technically add this in your definition of your initial element too…). Then, reset the decorators to be the ViewHelper and the HtmlTag. However, only define the DD tag instead of the full DD/DT suite. Finally, set the id to the element’s name plus ‘-element’ like the standard view does.

Good to go!

Removing the extra elements on Zend_Form for Submit Button is a post from: Aaron Saray