Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is this a pitfall that some have encountered? I have only recently discovered the notion of defining a constant to use globally but find myself attempting to define away each and every repetitive block of code (no matter how long).
Can I get two major reasons when to avoid using constants and one supportive reason/example illustrating great use?
The reason not to use constants - Having global data is typically considered bad practice. Since PHP has the ability to be object oriented, most well written software takes advantage of it. Here is a pretty good explanation without getting too lengthy about encapsulation and abstraction.
The reasons I consider using them, typically for things that are reusable, that I would like to change all at once. an example i can think of is contact information. It's usually in the footer, sometimes the header and typically on a contact page. If I want to reuse a template I can just change the information in one spot and effectively update it on the entire site. Usually the database credentials live in the same file. I'm not saying this is the best practice, but it's convenient to only have to make changes to one file for global changes to a website.
That's just my 2 cents.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
I'm trying to offer to the users (will be open to the internet, anyone can register) a WYSYWIG editor where users can input BLADE code to code their pages.
I want to provide them with the ability to create small functions to parse arrays/strings so I saw the #php tag of Blade useful for this.
My question: I can't find anywhere if this is like a sandboxed environment where only certain "safe" functions can be run or if this is more like an eval() and thus allowing people to basically inject PHP code to destroy the server and/or pull sensitive content?
I tried testing running basic commands with blade, but I would like a professional opinion on whether it's a bad idea regarding security (like, know exploits or other performance issues)
Thank you
Having a WYSIWIG open to the public on it's own has it's own challenges, because you will have to look into sanitizing the input/output otherwise you'll be opening yourself up to XSS attacks.
Allowing PHP code as well is obviously going to have lots of security risks, I wouldn't advise it personally - but it is technically possible. There are other online php sandbox editiors available, how exactly they secure themselves is beyond me. There are a lot of clever tricks that can be done, trying to whitelist or blacklist functions you deem as safe/unsafe is probably the way to go - but I still personally wouldn't feel comfortable implementing something like that. You may think you've covered all possible attacks, but it only takes one that bypasses what you've setup to essentially take over your server.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is it bad practice to make all of my web pages .PHP pages? My main reason for doing this would be to prevent myself from writing repeating code for things such as my nav bar and footer and having these in separate files so that I can 'include' them in a way similar to below.
<?php include('nav.php'); ?>
I was made aware that you can also use JavaScript to do this however my thoughts are that relying on JavaScript for something as crucial as a nav bar would be a bad idea.
This is more of an opinion question than anything. I would not consider this to be bad practice as long as the following conditions are met:
If someone browses to https://example.com/nav.php or any similar "include only" nothing bad can happen as a side-effect. By bad I mean that if the .php expects to be included from wider context and ends up wiping the database for example. Easy way to prevent this is to declare a constant in your main "page" files and check that in the includes.
You find this approach easy to manage. In a larger page you might end up with a lot of files that are included from different places and expect certain global variables to be present. In these cases structuring your directories correctly and documenting the code is essential.
Happy coding!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Actually I have a architecture question. I want to know, should I create multiple separate scripts (.php files) for some tasks which have both relevant together and different jobs? Or should I create just one script and use switch() function (of if-statement) to separate them of each other?
Let me say an example. I have a question-and-answer (Q&A) website. I want to know should I create two separate scripts for writing a question and writing an answer or should I create just one script for storing both answers and questions?
In other word:
One: One script
Storing_answers_questions.php
if ($_[POST] == 'q') {
// codes for storing a question are here
} else {
// codes for storing a answer are here
}
And then the action of both forms (question, answer) will be:
www.example.com/Storing_answers_questions.php
Two: Multiple scripts
Storing_answers.php
// codes for storing a answer are here
// ------------------------------------------------------------
Storing_questions.php
// codes for storing a question are here
And then the action of question-form will be:
Storing_questions.php
And answer-form will be:
Storing_answers.php
Well, which way?
I think it doesn't fall in the performance. It's a question of maintainability.
The question now is why and how?
Once your codes becomes long, it will be very confusing to look at your code. It will be harder to find what you're looking for. If you have seperated and organize files, it will lessen the risk for that to happen.
Real life scenario:
You have files in your computer, There is phptest.php, jstest.js,
jquerytest.js, csstest.css in one folder. Isn't it easier to find if you
seperate them in folder.
PHP->phptest.php
JavaScript->jstest.js, jquerytest.js
CSS->csstest.css
Seperated Files is also best for team project. You can assign this group to write a code for questions , and this group is for answers without stepping on their toes (Even if you are using version controls). They are organize.
And that's it, if you think this will have a very long complicated codes. Go for seperation.
In my experience the one-file style for this sort of thing would be typical, unless you have a deliberate flow in mind.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a computer science undergrad degree and during first year, during algorithm lessons, it is pushed into my head that i should not put return in any of condition branches; if, else.
The question and some answers support me. But there is a matter about my first PHP web site building experiment. PHP code samples on the Web tell that we 'must' use else die();.
I have prepared a Web site with 'my truth in my mind' without doing all the controls to handle all possible errors without any undesirable view on the pages of Web site. The database connection have exploded, thus some smart ***es tell me that i should use else die();.
Different coding styles have varying rules and there are many of them, so while that may violate a style that you've been taught, that doesn't mean it's a wrong thing to do.
Coding style recommendations are just that - recommendations; not a law. Their goal is to provide you with a set of rules that usually result in better-readable code. However, they are always influenced by somebody's own preferences and do not in any way mean that a piece of code is invalid.
Pick one and stick to it for your own benefit, but don't be surprised that other people have different coding styles.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have to maintain a website written in PHP running on version 5.3.22, smarty 2.6.19. The whole site is divided into two dependent subsites (one for the world and second one as CMS site for admin).
The company which developed this solution took the easy way out, just delivering already built product after few modifications. I'm on my way to merging everything into one suited piece.
My question is: is it worth to merge everything to native PHP, leaving Smarty convention, deliberately not using any of modern framework etc.? Is it worth to keep developing my own class for generating HTML (eg. createTag('th',attributes,value))? What are the benefits of using newest versions of PHP, Smarty and so on?
It is recommend to update software whenever there is an update available. The same goes for php, smarty and so on but whenever updating php, smarty or any other programming / scripting language have in mind you possibly have to refactor sourcecode - think twice.
Template engines such as smarty are very useful as they strictly divide business logic and the view.
The third point you mentioned are frameworks. As Kvothe mentioned already "Don't reinvent the wheel". That's why a lot of php frameworks exists in the www. Each has it advantages and disadvantages - I recommend to test some and choose the one you like most.