is this considered to be bad programming practice? I have includes in the beginning and end of my file in order to make templates.
so it is like this
beginning.php
<html>
some stuff
end.php
some stuff
</html>
user accessed files
include beginning.php
some stuff
include end.php
No it's perfectly fine. You can include files in places wherever you need to.
You can even use conditional statements to include specific php files as opposed to others. For example, your index page can have a conditional statement that checks to see if the user is logged in. If the user is not logged in, include a php file with the login form. If the user is logged in, include a php file that displays the user's profile information instead.
The only thing you'd want to worry about is making your pages too spaghettied by trivially splitting things into different files if they don't need to be. But all in all, you're good to go.
well, consider a designer point of view. will he/you find it difficult to make design changes to the file without affecting the server side implementation?
Using PHP this way is popular in design patterns such as the MVC, so you should be fine doing it. I wouldn't recommend it unless you have a clear structure to your projects because files can quickly become unorganised and messy.
Remember that PHP is generally finished executing before any HTML is outputted, so as long as it is logical to include PHP as-and-when, it should be fine.
Related
If I may ask, I would like to ask about "sessions", "controllers" and "session controllers".
So let's start at the beginning: I have heard of MVC and tried it in C# (VS), but while I could grasp the concept, I didn't understand implementation. It all seemed so strange. Now in PHP the concept became even more clear.
Now I would like to ask whether or not a "session controller" is like a controller for the session. It seems straight forward, in wording, but maybe I have it wrong. Although I would preferably not implement MVC in the current project I am working on, yet I would like to perform some sort of "controller" that manages groupings of session content.
Although I would like to ask if it is possible to have the following script in your application:
//path: c:/xampp/htdocs/starvationproject/root/index.php
<?php
include '../session/controller.php';
?>
<!DOCTYPE..........
//path: c:/xampp/htdocs/starvationproject/session/controller.php
//I have not coded this script yet, but it will perform tasks like
//setting the user, session variables etc.
<?php
session_start();
?>
// An important question here. If I include this file in the previous, can
// I safely say that the session has been started in index because of the
// include, or do you have to manually type out session_start();
// in each page?
Lastly, I would like to ask if this file structure is correct or not, or rather if it is standard or nor, or whatever:
Folder Structure
, where "multi" (as you can see) has a page named after each folder in "partial", where what I did is, based on the get request of the page in "multi", I included a partial, i.e:
if ($_GET['q'] == 'Add') {
include '../partial/stockAct/add.php';
}
else if ($_GET['q'] == 'Update') {
include '../partial/stockAct/update.php';
}
And then those "partial" files only held like a section with a form or something like that. As in the tv stays where it is, I'm just switching channels.
I'll do my best to help.
First let's talk about sessions. Sessions are used by the server to 'store' temporary information throughout a single browser session (this can be modified slightly but we won't go down that rabbit hole). In your specific situation, having a session Controller is unnecessary because the server handles all of the session logic. For example, on the login page, when the login form is pushed to a login script, you can simple add the user id to the session at that point and then no matter which page you move to, the user id will still remain in the session. The benefit is of course that you only need to set the session once and only access it when you require. This is where an MVC shines though as you can easily define a routing where all pages of a specific authentication type first go through to ensure the user is logged in/ has access to the page content.
For folder structure, I'd recommend some immediate changes. Firstly, I'm sure you are familiar with the talk of "public / public_html' folders? These folders are specifically name to represent the location where you put ALL of the files a front-end user would "see". This includes, front-end js files, css/ styles and in your case php PAGES. This folder SHOULD NOT however contain any back-end logic like database connections or verification scripts as this would give the front-end access to potentially sensitive information (ie. database login information which I am sure is found in your DB_Conn.php file).
To fix this I propose the following (assuming you would like to avoid the "MVC" structure).
ROOT
->Public //this is your WEB ROOT/ DOCUMENT ROOT folder
->Pages
->Style
->Scripts
->Assets
->Images
->etc.
->DB
->Connections
->db1_conn.php
->db2_conn.php
->Models
->User.php
->Posts.php
->Verification
->login.php
->etc
I'd like to finish with some advice as I used to build sites this way some time ago. MVCs take some time to learn, but their biggest advantage is the organization and flow of information. As a bonus, their process covers common issues like verification, security and data sanitization. Don't let them scare you, for the time it takes to learn then, they are well worth the capability you will gain from them.
I'd highly recommend Laravel. Version 5.5 just came out and oh boy is it a thing of beauty. Hope I could help at least a little!
This is probably a dumb question. I have a Web site that uses php and html with a bit of Javascript. I am trying to set it up so there are multiple landing pages. I think it would work if all the remaining .php files on the site were kept identical but there were separate index_a.php, index_b.php files, etc. The only problem is when the user clicks "Home" they of course get the root index.php. Is there a way to store the name (or some other indication) of what the user's landing page was for that session (using PHP session variables or I don't know what) and have the user directed to that page again when they click Home ?
Any help would be much appreciated (keeping in my mind I am a relative newby and any solution would need to be pretty simple and safe to load on a server). Any straightforward way way to do this ? It must be something that is fairly commonly required.
Short answer: yes
Smart answer: use a (mvc) framework of some kind which implements views and routes everything through a front controller.
Quick and dirty answer:
// anywhere
session_start();
$_SESSION['landing_page'] = 'landing-2.html';
// in your index.php
session_start();
include $_SESSION['landing_page'];
Note: if you use the code above, be sure the torn of the security gods will fall upon you.
The question is worded a bit strangely, but I couldn't figure out any other way. I'd like to know if there is a better model for doing this. Here's what I have now:
Say I'm editing a user on my application. I submit the form, and it POSTs to apply.php?ref=edituser. Then on apply.php, it has a large conditional to determine which settings are being submitted, based on the ref variable, at which point it runs that part of the script. If it succeeds or has an error, it uses header("Location: uedit.php") to return to the previous page, also setting $_SESSION['err'] with the error code. That page checks to see if the error code is set, and displays and unsets it if it is.
I feel like I might have too much in a single script. Any opinions on this?
Do multiple forms submit to it?
As a general rule a form doesn't submit to a model a form submits to a controller in the MVC structure. The controller then decides how it should handle everything. But if you comment everything well and don't think it is to much I wouldn't worry about it.
Depends on your style. Website I'm working on only uses 2 main php files. Only thing I would recommend is to make sure you comment well
The cons with this kind of system is like mentioned before, it can be hard to keep track of all code in a logic way.
An other con is that php is an interpreted language which means that the whole file need to be parsed on each run. That means that if you separate the code into different files instead of building a big one you will gain performance. But of course, if it is not to big it won't matter.
I've been told that it is unsecure to make database connections inside a PHP includes. For example If I have a login page and add an "include('process.php')" at the top of the page that has a database connection, is that unsecure?
For example If I have a login page and add an "include('process.php')" at the top of the page that has a database connection, is that unsecure?
No.
Maybe the person who told you this was talking about something else - like including a file using a dynamic value coming from a GET parameter, or using remote http:// includes, or as #AlienWebguy mentions, having the password include inside the web root. But using includes in itself is not insecure.
It's only insecure if you are storing your passwords literally in your PHP files. They should be declared outside of the web root. That being said, the lack of security is not due to the use of the include() function.
In and of itself, no, it is not insecure. How it's implemented inside the include is of course a different story.
That's the way I've always done it. I make sure that the include is in a different directory that has open permisions and that the directory your writing in has locked permisions. Hopefully that makes sense.
This question is way too broad to get a good answer from anyone. Short answer is no, there's nothing inherently insecure about including a file that connects to a database. However, if you write code that isn't written properly, then yes it may be insecure to do this.
Since using "include('process.php')" is exactly the same as pasting 'process.php' into the code of the other file, that should not be, per se, a security issue. The insecurity could be in your code, not in the fact the you use the "include". In fact, it could maybe improve the safety of your code, due the reuse.
StackOverflow is telling me this is a subjective question, but I think it's a matter of fact!
I have a number of scripts that I'm using on different parts of my site. In terms of making fewer http requests, I know it's better to combine all of these scripts into one .js file. However, isn't a waste of time for a page to call a .js full of 10 or 15 different functions when it's only using one?
The other method I am using is to use PHP conditional statements...
<?php if( is_page() ) { >
$(document).ready(function(){
...
});
<?php } ?>
What's the best method or comination of these methods?
Seeing as the script file is cached by the browser and needs to be loaded only once, it is usually the smartest thing to in fact combine all JS code into one file.
It may be different if you have huge libraries upward of 100 kilobytes that get used only by certain users (e.g. users that log in). In such cases, it makes sense to make distinctions. Otherwise, I'd say go with one big file.
I would say, provided you expect users to require the vast majority of these resources as they browse your site, taking the hit all at once isn't much of an issue.
You need to make sure that your homepage loads quickly enough though, maybe consider a cut down script file for the homepage, and a fully bloated version for the other pages. Or separate out the truly required on every page features into a file that is included on the homepage, and the other features into an -extra file. Then include both files on pages which require them. The browser will already have cached the basic file from the homepage.