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 form which has a textarea input. This text area will have some custom "tags" that I would like to make, similar to the * operator in SO's textarea which gets processed and interpreted as italics or bold depending on how it's used.
The end goal is to process this long string of text, make any formatting modifications needed, then write it to a database table. I'm not really sure how to approach this problem, however.
My first thought was to use $_POST, but I'm unsure it it's a good idea to store very large strings in this array as I cannot find any information as to how much data it is good to store in this array. Is there some best practice for transferring large amounts of data to another page? Should I be using jQuery for this? If so, how?
$_POST will most likely be used, whether or not you do this with jQuery. The default limit of $_POST is already high enough to handle most user input, short of file uploads. If you need it to be greater than 8MB, you can change that on the webserver in your php.ini file. I've had a similar application, and in testing I had no problem pasting >64MB into my textarea.
I would also consider changing the order of operations a little bit. I'd do one or the other of the following:
1) Rather than format your text prior to db insertion, format it on the way back out to the browser. That way, if you change the way your input gets formatted, you have the original data to apply it to. It's a little more work for the server when displaying the data, but it's likely you'll have a much easier time maintaining your application down the line.
2) Store both the formatted text and the raw text in the database. This has the benefit of speed by not having to format it on its way to the user every time it's called, and also allows you the ability to build a means of changing the format of the data later, at some coding expense.
EDIT: As pal4life stated in a comment, you want to avoid executing any of the user input. Essentially, if your method is to save the input to a file, and then recall it with an include() or require(), you open yourself up to some severe security vulnerabilities. An attacker could upload code like <?php var_dump($conn); or much worse. I believe you may safely readfile(), however the browser is still vulnerable to any potential javascript that may have been placed there by an attacker.
Using $_POST is a pretty good way to start, if it's getting bigger then 8MB change the php.ini. If it's getting much larger you can start slice your string and send the chunks via jQuery to your web server and concatenate them afterwards.
But at the first run I would prefer with the standard way and use $_POST.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a series of articles in files that are included in dynamic pages. I would like delete all the files and put the content in a database.
However, some of the articles include PHP code. I was surprised to learn on a recent thread that you can put PHP code in a MySQL database table. However, I forgot to ask how to do it. Can someone show me how you would modify the following text (which includes an echo value and an include) so that it can be stored in a database table?
<p>Mammals and reptiles evolved from a common ancestor.</p>
<h3><a name="Internal" id="Internal"></a><?php echo $EvoHeader; ?></h3>
<?php require_once($BaseINC."/AContent/Child/Life/Features/Classification/Order/Mammals.php"); ?>
<p>Evolution continues today.</p>
I see that nobody addresses how to run that code once you fetch it, but only how to escape it, etc... I don't think OP needs PHP snippets to show them on the page, but to run them.
If you want to run the PHP code after you fetch it from the database, you can use eval. But I strongly suggest you don't do it. There are millions of articles about it and why it's not safe. So, unless you're 110% sure you know what you're doing, don't do it.
However, since I doubt you'd need a dynamic code within a dynamic piece of code, I suggest you put the rendered version of every page into the database. This means that you take the output of each file, including whatever those php lines output (with their echoes and includes), and store it all together like that. If you still need some dynamic code within that (like maybe the logged user's name, or the current date, etc.), I'd suggest you add those after you fetch the data from the database, either by setting flags, making exceptions, whatever works.
The bottom line: use your database for content, settings, etc... do not use it for running code from it even though there are ways to do it.
Nice answers about eval: When is eval evil in php?
You might also find this topic interesting (no matter it's about Drupal): https://drupal.stackexchange.com/questions/70297/php-in-database-bad-practice-but
PHP code is just ordinary text as far as the database is concerned.
The issue isn't putting it in some special format, but escaping it properly. The best way is to use prepared statements, via MySQLi or PDO. You can also use mysqli_real_escape_string().
Edit: Based on your comment, it sounds like you are doing something like this: get the code from the database, then echo it. You're right, that will result in it being output as text. You would have to execute it with eval() or something, which is a very bad idea. As others have pointed out, this is not an ideal way to store PHP code; it will be hard to maintain, open up some security problems, probably result in naming conflicts, and generally introduce more headaches than it resolves.
If we forget that php code is only a text, and you just want not to save normal php code into your database, You can first serialize your php code, and then insert it into your database. While fetching your php code from database in future, you can unserialize it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am planing to build a simple CMS (with PHP) for my own educational needs and I ran into a problem with design as I have never encountered this in any book or tutorial.
If I wanted to let used mess around the colors for example. How do I do that? The only idea I had was make a database with basically all such a options and then echo them to the site as normal CSS. But thet would mean it would load from DB every single time someone visits the webasite. It seems to me like it could overload the website. But again, I have never encountered such a problem. Or is there a way of doing this much more easily?
Thanks for every answer!
EDIT:
I would like to create a system that enables user to change css via CMS. For example background color, drop-down menu colors, text sizes, fonts and a lot of other stuff handeled by CSS. Simple customization.
So I was asking 2 questions.
How? What system should I use? No book/tutorial I read never covered editing CSS files using PHP so I have no idea how to do that. Or maybe there are better ways of doing it?
I had idea how I would store all customisable data. In database I wanted to know how big it can be and whether it would be a problem when posibly tens or maybe even houndreds of variables would be loading to the site.
EDIT2:
And btw I never worked with Wordpress or other CMS and I kind of expected that options like what I am looking for are present there, is that true? In my mind such a feature is essential for user inexperienced with computers. But from what I understand from link provided by Sam (http://css-tricks.com/css-variables-with-php/), it's not common. It's actually quite complicated thing and might harm performance of the website.
I hope I made my question clear now.
I know this has tons of downvotes, but you can cache your database queries. You can also mimic a CSS file using the header type in PHP. See http://css-tricks.com/css-variables-with-php/
This will allow the browser to cache the CSS file that was generated by PHP & MySQL. This means the database will only be called when the cache expires.
In terms of size you will never reach a limit with what you are describing.
Update
These sort of features are a bit unorthodox, using a cached version of the generated CSS file is basically mandatory.
What you can do is include a text editor within the CMS to edit the CSS file, each user can have their own CSS file that overrides the default one if changed. By letting them edit it directly they can change the layout themselves. You can even limit them to only changing colours / font-sizes etc.
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 9 years ago.
Improve this question
$('#tip2').qtip({
content: {
text: '<?php echo "I do work."?>'
},
In this case I'm using a jquery plugin but that doesn't matter for the question I believe.
I thought I had to go trough json calls (or other ajax call methods) because php runs first, and only later runs javascript, but, I actually tested this code, and it actually displays the text.
Can anyone please take some words to explain, on what circumstances should we NOT use php inside javascript. Is this one of them? If so, why?
I'm clearly not getting some client side, and server side workflow... please forgive my newbielity towards those matters.
Sorry if this was an inconvenient question.
Update
Please note that I'm asking about facts. Not opinions.
Someone states:
"You shouldn't do that way."
I'm asking:
"What facts (not opinions) sustain that claim?"
It might be sensible to externalise most, if not all, of your JavaScript to another, static file for caching reasons.
It is possible to have a PHP file generate JavaScript, but as all dynamic content, it can not cache as well (while you can set-up caching headers, changes to the generated content will not be immediate, so you'll be forced to find a compromise between content accuracy and bandwidth savings).
I would externalise your example as so:
$('#tip2').qtip({
content: {
text: my_var
},
Then create the following <script> block in your dynamic file before linking the static one:
my_var = '<?php echo 'I do work'; ?>';
This way, the vast majority of your JavaScript will be static, and eligible for Max-Age caching.
To provide you with a real-world example, I have recently implemented a pure JS plotting library that draws discrete data onto a canvas. The data to be plotted is supplied by the CGI (I didn't use PHP, but it shouldn't matter), so I used this approach to declare an array of values in the dynamic file, while externalising the actual handling and drawing code. It works beautifully, uses minimum bandwidth due to caching nicely, and is still very maintainable.
Unlike some other answers, I won't say you should avoid mixing server-side code with client-side; hell, HTML is client-side code that you are generating server-side. Depending on your needs, mixing JS and CGI can extend your possibilities, and applying my caching trick, there is no real downside.
A php file is interpreted by the web server and converted to a pure html file. That html file is then passed to the client's browser, which displays it.
In your case, the php echo is rendered as a string in the html page.
Keep in mind that if you do what you did in your example, the values rendered to the page are the values that exist when the page is rendered by php.
You should try not to use it as much as possible. However, there might be some very rare cases when you do need to pass values from your PHP code (say from a $_SESSION array) into your jQuery/JavaScript functions. In that case, if you don't have any other option then you can pass values like you did above. But in all other cases, try not to do it as much as possible since it is not a good practice. When you are combining 2 different languages like this, there might be cases when you get unpredictable behavior from the application/web-page.
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 9 years ago.
Improve this question
If I'm hosting a website on a server that has PHP, would I ever need to host a .html file on it? PHP files can have raw HTML code inside of them as well as the added benefit of being able to inject PHP code, so isn't PHP a more inclusive language?
Serving HTML is generally a lot easier for the webserver than serving a page that has to be run through the PHP interpreter.
This can have huge benefits on high-traffic sites. For example, the Obama campaign ran their fundraising platform with a lot of static HTML for that reason.
it always can be situation that you would need to add e.g. maintenance page in pure html
It's not a question of whether you can simply make everything "a PHP file" but rather a question of whether any given file needs to be PHP. If a file contains only static content, there's no need for any server-side processing. So in such cases it would make more sense to make it an HTML file.
Don't look for a tool that covers all cases, look for the right tool for each case.
I read that it is recommended to have <?php flush(); ?> between </head> and <body>. I would assume that this should apply to every webpage, there really isn't a solid reason as to why you would only use HTML.
I agree with ceejayoz, but if that's not a problem for you, then using PHP is great.
It depends on your purpose. If your page uses PHP then the file extension needs to end in .php. If you don't have any PHP then you can just save the page with a .html file extension. A major difference is that PHP is processed on the server side. Meaning the user(client) will not see your PHP code if he views the source, he'll see what was processed from the server in the form of HTML.
One advantage of using .php files over HTML (in this trivial case) is that, you can wrap up all your footer files(if the are the same) or any redundant files, like sidebar, advertisingand just include them in your other files, instead of having to create/manage individual files later, So, you can just open one footer.php file and make as many changes as you want without wasting any time.
Your basic understanding is correct. You can absolutely have a .php file that has only HTML in it and given a simple page and a simple site there would be little difference.
However, the PHP preprocessor adds a bit of overhead to check for PHP code in the file. In most cases this is insignificant, but on a highly optimized site you probably would not want the pages to be processed for nothing.
I wouldn't say that PHP is a more inclusive language though, HTML and PHP are two different things. In many cases (but by no means all) PHP generates HTML. It's just that the resulting HTML from a PHP script that has no PHP tags in it would most likely be the same as it would be for an html file. Although it is likely that HTTP Response Headers would be different and there are other things outside of the file content itself that could be slightlu
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'm working on a site which requires a very simple CMS - basically there's a block of text on the homepage that needs to be editable by the client. Their current hosting plan doesn't allow for a database, and including one will cost an extra $X a month which I think is unnecessary for such a basic system.
The site is currently built using Codeignitor. I'm planning to write the CMS part of it using either flat PHP or TXT files, are there alternative methods worth considering, and what are the pros/cons?
Okay, so further to this, I've opted for a custom flatfile system. I looked at a few of the recommended non DB CMS systems and they seem quite good - particularly this one which I later found: http://get-simple.info/
The reason for building my own is mainly due to the fact that the site is already on the Codeignitor Framework, and I don't want to rebuild it using a different one.
So my question now is - if my system is storing data in two txt files: one for userdata and one for site content, are there massive security issues if I set the sitecontent file permissions to RW? The site is quite small and I can't imagine anyone would want to hack it, but I'd still like to know if there are any major security implications.
Try http://www.opensourcecms.com/
example of some that might interest you
PivotX
pluck
razorCMS
cushyCMS
its ftp's into your hosting account, reads your html, and looks for tags that have a class="cushy" and makes those content feilds editable. its good forwhat your wanting.
I once solved this problem by simply putting markers in an HTML file, as HTML comments, and then had my PHP script parse the file and insert the desired text in between the markers. Done this way, you need no other files other than the PHP that handles the form submission from the CMS and a static HTML page.
In words, read the file into a string, explode() the string using the marker as the delimiter, modify the second (if you have a single editable section enclosed by the markers) array element to contain the new text submitted by the user, then implode the array back into the string, then write the string back as the complete file.
What about sqlite? it is just a file, no need to install anything? But if this is also not welcome, you could just keep the contents in txt files and have a php to read it, put to your template.