php开发不显示错误_PHP开发人员常见的7个错误

php开发不显示错误

Back at the end of June, TopTal, the freelance marketplace, published a post about 10 Most Common Mistakes PHP Programmers Make. The list wasn’t exhaustive, but it was well written and pointed out some very interesting pitfalls one should be wary of – even if I wouldn’t personally list the mistakes as very common.

早在6月底，自由市场TopTal就发表了一篇关于PHP程序员最常犯的10个错误的文章。 该列表并不详尽，但是写得很好，并指出了一些非常有趣的陷阱，应该谨防–即使我个人不会将这些错误列举为非常常见。

I encourage you to give it a thorough read – it has some truly valuable information you should be aware of – especially the first eight points. A couple days back, Anna Filina expanded on the list with seven new entries. While less specific and common, her points still carry weight and should be considered when developing.

我鼓励您仔细阅读它-它具有一些您应该了解的真正有价值的信息-特别是前八点。 几天前， 安娜·菲利娜 ( Anna Filina)在名单上增加了七个新成员。 尽管她的观点不够具体和普遍，但仍具有重要性，在发展时应予以考虑。

PHP开发人员经常犯的7个错误 (7 More Mistakes PHP Developers Often Make)

I was asked by someone from TopTal to take a look at their list and potentially contribute, and some of our followers on social networks expressed an interest in seeing the list continued, too, so I’d like to take this opportunity to add some of my own entries to this list that I repeatedly need to warn my team members or followers about.

TopTal的某人要求我查看他们的列表并可能做出贡献，我们社交网络上的一些关注者也表示有兴趣继续看到该列表，因此，我想借此机会添加一些我自己在此列表中的条目，我需要反复警告我的团队成员或关注者。

1.使用mysql扩展 (1. Using the mysql extension)

This news is quite old, but the number of developers oblivious to the fact is worrying. When using SQL databases, specifically MySQL, far too many developers still opt for the mysql extension. The mysql extension is officially deprecated. It’s insecure, unreliable, doesn’t support SSL and is missing some modern MySQL features. It also generates deprecation notices which don’t break your app, they just appear at the top of your app. Hilariously, what this means is that it’s also possible to simply Google for all the various sites that use this insecure setup by simply looking for this. The world of hurt those apps are exposed to due to this mess is staggering.

这个消息已经很久了，但是忽略这一事实的开发人员的数量令人担忧。 当使用SQL数据库(特别是MySQL)时，仍然有太多的开发人员选择mysql扩展。 mysql扩展已正式弃用 。 它不安全，不可靠，不支持SSL，并且缺少一些现代MySQL功能。 它还会生成不会破坏您应用程序的弃用通知，它们只会出现在您应用程序的顶部。 欢快的，这意味着它也可以简单地谷歌为所有通过简单地寻找使用不安全设置各个站点此 。 这些应用程序因这些混乱而遭受的伤害世界令人震惊。

Instead of using mysql, opt for one of the alternatives: MySQLi, or PDO. For example, using MySQLi instead is almost as simple as adding the letter “i” to the end of the API calls:

代替使用mysql，而是选择一种替代方法：MySQLi或PDO。 例如，使用MySQLi几乎就像在API调用的末尾添加字母“ i”一样简单：

$c = mysql_connect("host", "user", "pass");
mysql_select_db("database");
$result = mysql_query("SELECT * FROM posts LIMIT 1");
$row = mysql_fetch_assoc($result);

vs

与

$mysqli = new mysqli("host", "user", "pass", "database");
$result = $mysqli->query("SELECT * FROM posts LIMIT 1");
$row = $result->fetch_assoc();

That’s all it took to make the setup immeasurably more secure.

这就是使安装更加安全的过程。

You should opt for PDO, though. More on that in point 2.

不过，您应该选择PDO。 关于第2点的更多信息。

2.不使用PDO (2. Not using PDO)

Don’t get me wrong, mysqli is (quite literally) generations ahead of the ancient mysql extension. It’s kept up to date, secure, reliable and fast. However, it’s mysql specific. Using PDO instead would let you use some wonderfully practical object oriented syntax, and would prepare you for tango with other SQL databases like PostgreSQL, MS SQL, and more. What’s more, PDO will let you use named parameters, a feature so useful, few people can imagine going to anything else after having taken proper advantage of it. Last but not least, there’s this: you can inject fetched data directly into a new object, which is a delightful timesaver in large projects.

别误会，mysqli(从字面上看)比古老的mysql扩展要先进。 它保持最新，安全，可靠和快速。 但是，它是特定于mysql的。 相反，使用PDO可以使您使用一些非常实用的面向对象语法，并且可以为其他SQL数据库(例如PostgreSQL，MS SQL等)探戈做好准备。 更重要的是，PDO允许您使用命名参数 ，此功能非常有用，很少有人可以想象得到充分利用后再去做其他事情。 最后但并非最不重要的一点是 ：您可以将获取的数据直接注入到新对象中，这在大型项目中可以节省时间。

3.不重写URL (3. Not rewriting URLs)

Another commonly ignored and easy to fix issue. URLs like myapp.com/index.php?p=34&g=24 are just not acceptable in this day and age. Due to it being incredibly difficult to write a good URL rewriting guide that would cover every server and framework out there, almost every framework has a guide on how to set up clean URLs (Laravel, Phalcon, Symfony, Zend) and any that don’t just aren’t worth using – they obviously don’t care about modern practices.

另一个通常被忽略且易于修复的问题。 在当今时代，诸如myapp.com/index.php?p=34&g=24类的网址是不可接受的。 由于编写覆盖所有服务器和框架的良好URL重写指南非常困难，因此几乎每个框架都提供了有关如何设置干净URL( Laravel ， Phalcon ， Symfony ， Zend )的指南，以及所有不该使用的 URL指南。只是不值得使用-他们显然不在乎现代实践。

4.抑制错误 (4. Suppressing errors)

I wrote about this in a previous article, but it’s worth mentioning again. Any time you find yourself using the @ operator, reconsider and approach the problem from a different angle more carefully. Take my word for it when I say that 20 lines of boilerplate cURL code around an app’s functionality is better than a single line with the @ operator in front of it.

我在上一篇文章中写过关于此的内容，但值得再次提及。 每当您发现自己使用@运算符时，请从另一个角度重新考虑并更仔细地解决问题。 当我说围绕应用程序功能的20行样例cURL代码比前面带有@运算符的一行更好时，请相信我。

I’ve found through personal experimentation that a good approach is the one I advocate in the original post – turn all your notices into fatal errors. Making sure nothing gets logged into the error logs because there’s literally nothing to log is better than pretending poop isn’t hitting the fan by holding @ in front of your eyes.

通过个人试验，我发现一种好的方法是我在原始帖子中主张的方法–将您所有的通知变成致命的错误。 确保没有任何东西记录到错误日志中，因为实际上没有什么记录要比假装便便更好，因为没有通过按住@来摆弄大便。

We recently covered some Heroku add-ons for production ready PHP apps, and one of those was the excellent Papertrail – an add-on which lets you push all your app’s errors to their backend for easier searching, grouping, and elimination later on; so even if some errors do happen, it’s better to let them be logged and get rid of them by fixing your code, than silencing them and playing dumb in front of your users.

我们最近介绍了一些可用于生产环境PHP应用程序的Heroku附加组件 ，其中之一就是出色的Papertrail –一个附加组件，可让您将所有应用程序的错误都推送到其后端，以便日后更轻松地进行搜索，分组和消除。 因此，即使确实发生了某些错误，也要通过修复代码让它们记录下来并摆脱它们，而不是使它们静默并在用户面前傻瓜化。

5.分配条件 (5. Assigning in Conditions)

Even experienced developers sometimes have a slip of the finger and write if ($condition = 'value') { instead of if ($condition == 'value') {. Our hands will slip, our keyboards won’t register the keypress, we’ll end up pasting from another part of the code where the assignment actually happened – it happens, and we usually find out only when we run the app.

即使是经验丰富的开发人员，有时也会轻描淡写，然后写下if ($condition = 'value') {而不是if ($condition == 'value') { 我们的手会滑落，我们的键盘将不会注册按键，我们最终将从实际发生分配的代码的另一部分粘贴-它发生了，并且通常只有在运行应用程序时才能发现。

There are several ways to completely avoid this:

有几种方法可以完全避免这种情况：

1. Use a decent IDE. Any good IDE (like PhpStorm, for example) will warn you of “assignment in condition” issues when it detects them.
   使用一个体面的IDE。 任何好的IDE(例如PhpStorm)在检测到它们时都会警告您“状态分配”问题。

2. Use “Yoda Conditions”. You’ll see these in many popular projects, even large frameworks. By inverting the comparison (as in, if ('value' = $condition) {), weaker IDEs will notice the problem, too. Some consider the Yoda syntax annoying and pointless, a lifeline where there should be none (“be more carefuly with your code, dammit”), but to each his own – if it helps someone, I’m all for it. If we were all elitists, WordPress and Zend Framework wouldn’t exist.

   使用“ Yoda条件” 。 您会在许多受欢迎的项目中看到这些，甚至在大型框架中也是如此。 通过反转比较(例如， if ('value' = $condition) { )，较弱的IDE也会注意到该问题。 有些人认为Yoda语法令人讨厌且毫无意义，这是一条生命线，应该没有生命线(“对代码要格外小心，该死”)，但是对每个人来说，如果有帮助，我全力以赴。 如果我们都是精英人士，那么WordPress和Zend Framework就不会存在。

3. By simply keeping it in mind, you’ll develop an eye reflex to check for it every time you write it. All it takes is practice, but it happens even to the best devs and that’s where 1. and 2. come in handy.
   通过简单地记住它，您将开发出眼睛反射功能，以便在每次编写时都进行检查。 它所需要的只是实践，但即使是最优秀的开发人员也要实践，这是1.和2.派上用场的地方。

6.太透明 (6. Being Too Transparent)

Saying this might stir up some controversy, but here goes anyway. Unless you have 100% confidence in the framework’s developers, or don’t operate high-profit, high-traffic business critical applications, you should always strive to obscure your back-end ways – not broadcasting which framework your app is based on can actually help in preventing attacks, should a security vulnerability of that framework be discovered. For example:

说这可能会引起一些争议，但是无论如何这还是可行的。 除非您对框架的开发人员有100％的信心，或者不运行高利润，高流量的业务关键型应用程序，否则您应该始终努力掩盖您的后端方式-不要广播您的应用程序所基于的框架实际上如果发现该框架的安全漏洞，则有助于防止攻击。 例如：

If you use Symfony2 translator and have a route with a {_locale} parameter upgrade NOW ! http://t.co/jihXHB8MzT

如果您使用Symfony2转换器，并且具有带有{_locale}参数的路由，请立即升级！ http://t.co/jihXHB8MzT

— Jérémy DERUSSÉ (@jderusse) July 15, 2014

—JérémyDERUSSÉ(@jderusse) 2014年7月15日

In this tweet, knowledge of a serious code injection issue is being broadcast into public domain. This is great if you’re at work and can upgrade immediately without devops issues and getting the team huddled up first, but for most people and companies using Symfony, this is not the case. Even though Symfony can be upgraded via Composer (as Ryan mentioned in the comments below), it usually takes a while to get approval in large teams with multi-tier environments. All websites using this translator approach that are declared Symfony users were (are?) therefore exposed to this vulnerability until fixed.

在此推文中，有关严重代码注入问题的知识正在广播到公共领域。 如果您在工作中并且可以立即升级而不会出现开发问题，并且首先使团队变得拥挤，那就很棒了，但是对于大多数使用Symfony的人和公司而言，情况并非如此。 即使Symfony可以通过Composer进行升级(如Ryan在下面的评论中所述)，通常也需要一段时间才能在具有多层环境的大型团队中获得批准。 因此，所有已声明使用Symfony用户的使用此翻译器方法的网站都将暴露于此漏洞，直到修复。

Using Symfony in the example above was just that – an example. Similar situations have arisen with countless other software over the years. Back when I still used Zend Framework commercially, we had this happen too, and suffered an attack due to it. WordPress has had its share of security gaffes and we know how high of a percentage of websites out there they power. These things happen, and sometimes, open source and transparency aren’t the best approach when dealing with applications that carry the majority of a company’s revenue stream.

在上面的示例中使用Symfony只是一个示例。 多年来，无数其他软件也出现了类似情况。 当我仍然在商业上使用Zend Framework时，我们也发生了这种情况，并因此遭受了攻击。 WordPress在安全性方面有其份额，我们知道他们所支持的网站比例很高。 这些事情发生了，有时，在处理占据公司大部分收入来源的应用程序时，开源和透明性并不是最佳方法。

7.不删除开发配置 (7. Not Removing Development Configurations)

Last but not least, development configuration removal should be mentioned. Quite recently (and it’s an honest coincidence I’m mentioning Symfony here again), Cnet suffered an attack due to not removing their development configuration.

最后但并非最不重要的一点是，应提及删除开发配置。 最近(这是我在这里再次提到Symfony的一个巧合，这确实是一个巧合)，Cnet由于未删除其开发配置而遭受了攻击 。

Uhmmm no: http://t.co/rAQis1ycWq #security #symfony

嗯，没有： http : //t.co/rAQis1ycWq #security #symfony

— Marco Pivetta (@Ocramius) July 15, 2014

— Marco Pivetta(@Ocramius) 2014年7月15日

Cnet, one of the world’s largest tech news sites, is based on Symfony. Symfony, as you might know, features two entry points to your application: app.php and app_dev.php. By pointing your browser to one, you get the production environment. By pointing to the one with the _dev suffix, you obviously get the development version, which features a debugger, sensitive data, and more. Whether this is good or bad is a subject of many discussions (again, thanks to Ryan for pointing this out), but it’s undeniable that it opens some clumsier developers to errors such as those Cnet suffered from. What’s more, any other URLs accessed when on app_dev will get redirected to other app_dev URLs. In other words, it’s not just the index page that launches in development mode, it’s the entire website – in Cnet’s case, that’s a lot of access.

Cnet是全球最大的科技新闻网站之一，以Symfony为基础。 您可能知道，Symfony具有应用程序的两个入口点： app.php和app_dev.php 。 通过将浏览器指向一个浏览器，即可获得生产环境。 通过指向带有_dev后缀的版本，您显然会获得开发版本，该版本具有调试器，敏感数据等。 这是好是坏是许多讨论的主题(再次感谢Ryan指出了这一点)，但是不可否认的是，它使一些笨拙的开发人员容易遭受Cnet等错误的困扰。 此外，在app_dev上访问的任何其他URL app_dev将重定向到其他app_dev URL。 换句话说，在开发模式下启动的不仅是索引页面，还包括整个网站–对于Cnet来说，访问量很大。

If you follow the discussion on Twitter, it gets emabrrasingly sad really fast – and what’s even sadder is that it could have been avoided in a second’s work:

如果您关注Twitter上的讨论，那么它很快就会令人难以置信的悲伤-甚至更可悲的是，可以在一秒钟的工作中避免它：

1. The devs could have removed app_dev.php from the production servers

   开发人员可能已经从生产服务器中删除了app_dev.php

2. The devs could have whitelisted IPs allowed to access app_dev.php, which is how it works by default unless you loosen those restrictions up.

   开发人员可能已将允许访问app_dev.php IP列入白名单，除非您放宽了这些限制，否则默认情况下这是工作方式。

Either of these approaches would have completely prevented all problems. Remember, when pushing to production, make sure your development configuration is either fully inaccessible, or accessible only to a whitelisted set of IPs.

这些方法中的任何一种都可以完全避免所有问题。 请记住，在推向生产阶段时，请确保您的开发配置是完全不可访问的，或者仅可被列入白名单的IP访问。

结论 (Conclusion)

How do you feel about this list? Does it cover common aspects or is it too esoteric? Do you have some more common pitfalls the three posts in total have failed to mention? Let me know in the comments below and we’ll update the post if your advice is sound!

您对此清单有何看法？ 它涵盖了共同的方面还是太深奥了？ 您是否还有一些更常见的陷阱，而这三个职位一共没有提及？ 在下面的评论中让我知道，如果您的建议是正确的，我们将更新该帖子！

翻译自: https://www.sitepoint.com/7-mistakes-commonly-made-php-developers/

php开发不显示错误