premiso
-
Posts
6,951 -
Joined
-
Last visited
-
Days Won
2
Everything posted by premiso
-
There are a couple of PHP 3rd party libraries for Excel: http://phpexcel.codeplex.com/ http://code.google.com/p/php-excel/ Not sure if one is better than the other. If the sheet is in CSV format there is always, fgetscsv which parses CSV files for you.
-
The problem is you are echoing out an actual image, so the page thinks you are just displaying an image. In order to do this, you should have a seperate script, image.php and pass variables via GET to it: image.php: <?php if (!empty($_GET['text'])) { // Set the content-type header('Content-Type: image/png'); // Create the image $im = imagecreatetruecolor(400, 30); // Create some colors $white = imagecolorallocate($im, 255, 255, 255); $black = imagecolorallocate($im, 0, 0, 0); imagefilledrectangle($im, 0, 0, 399, 29, $white); // The text to draw $text = $_GET['text']; $textSize = $_GET['size']; $font = 'corbelb.ttf'; // Add the text //imagettftext($im, 20, 0, 10, 20, $black, $font, $text); imagettftext($im, $textSize, 0, 10, 20, $black, $font, $text); // Using imagepng() results in clearer text compared with imagejpeg() $img = imagepng($im); imagedestroy($im); } index.php: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>untitled</title> </head> <body> <form action="index.php" method="post"> <input type="text" name="text" /> <select name="size"> <option value="10">10</option> <option value="12">12</option> <option value="14">14</option> <option value="18">18</option> <option value="24">24</option> <option value="30">30</option> <option value="36">36</option> </select> <input type="submit" name="submit" value="Set →" /> </form> <?php if (!empty($_POST['submit'])) { echo '<img src="image.php?text=' . $_POST['text'] . '&size='.$_POST['size'].'" />'; } ?> </body> </html> And that should get you what you are looking for (pending any syntax errors on my end).
-
This is not a PHP issue by any means, nor is it really a CSS issue. But PHP is completely irrelevant. Your problem is in your HTML link tag within the type attribute. It should be: type="text/css"
-
Microsoft acquires Skype - but what else do they own!!
premiso replied to titan21's topic in Miscellaneous
Whoa man... *premiso 's mind has been blown. -
RewriteRule ^products/.*/(.*)/action/(.*)$ something.php?page=products&category=$1&action=$2 [L] RewriteRule ^products/.*/(.*)$ something.php?page=products&category=$1 [L] Since you know products is static (not sure if by category you mean the actual category or just the word) you use that as your anchor. The rest is pretty self explanatory. Trying to do it all dynamically would be just a pain in the butt and quite unnecessary. This should get you what you are after.
-
Need help from a PHP accountant LOL
premiso replied to Freedom-n-Democrazy's topic in PHP Coding Help
Wtf since when? -
You should have used Recuva. It can generally restore files that were just soft deleted (even a quick format). But doing a system restore may have overwritten the data. I would still try it to see. But yea, that is your best bet.
-
No problem. All in all I was just explaining WHY I would not use your service. Simple as that. And yes that VPS Provider is true, as I am a customer with them and my sites on the 128M's work great. So yea, maybe a bit off topic, however, the origin of it pertained to the topic at hand. No I would not pay that much for it. Why, because I know of a provider that offers me more for way less. Comparing your setup to theirs those is Apples to Oranges. You offer far less space, and bandwidth, but potentially better Website access without it being bogged down. I get that and you do not offer a VPS type solution, it is more of a "managed hosting". Where as that VPS is unmanaged, which reduces the costs significantly. So for the average user, that might be a good deal. However, I am not an average user, and I would not buy into a hosting plan like that. My 2 cents on it. Done and done.
-
ErrorDocument 404 /home/test/public_html/404_error.php This should be the file relative to the web url. So it should just be 404_error.php ErrorDocument 404 404_error.php Which should work.
-
preg_match_all Help with Whitespace and Newlines
premiso replied to savagenoob's topic in PHP Coding Help
Whelp, there's your problem...godaddy. Anyhow beside the point. $proname1 = preg_match_all('/<div class=["\']agentContainer["\']>.*<div class="strong">(.*?)<\/div>/s', $html, $name1); The 's' modifier makes it so that the . ignores new line characters. So it should match like that. Since I highly doubt you want to keep the quote type matched, use a bracket and just put both quotes in there, this will match one of them. After you get the matches out, you just need to run trim on the variables in $name1 to remove the line breaks and extra spaces and this should be good. FYI, post regex questions in the Regex forum. The m tags are using to link to the PHP Manual, use code or php tags for putting code in. -
preg_match_all Help with Whitespace and Newlines
premiso replied to savagenoob's topic in PHP Coding Help
Since I was interested on making it work for my own purposes, here is how it would be done: <?php $string = '<html><head></head><body> <div class="anotherClass"> </div> <div class="agentContainer"> <div class="strong"> Blah Blah Company </div> </div> <div class="moreDiv"> </div></body></html>'; $doc = new DOMDocument(); $doc->loadHTML($string); $xpath = new DOMXPath($doc); //$divs = $doc->getElementsByTagName('div'); $query = '*//div[@class="agentContainer"]//div[@class="strong"]'; $entries = $xpath->query($query); foreach ($entries as $entry) { echo trim($entry->nodeValue) . "\n\n"; } -
preg_match_all Help with Whitespace and Newlines
premiso replied to savagenoob's topic in PHP Coding Help
If you have valid HTML (if not make it valid) use the DOM. This makes parsing HTML and pulling out items so much easier than using regex, plus it does not require certain attributes to be in specific locations etc. -
It is...but luckily it is true. Been with them since March and after a move from HE to Coresite in July, still going strong, 61 days uptime. I have a WP Blog hosted on one (not much traffic to it). One for a VPN, one for a development box, then I have some bigger boxes that host my major sites and my backup data which goes to CrashPlan automatically. So yea, they offer a great service and I am very pleased with all of my BuyVM Boxes
-
$15/Year. BuyVM, I actually have 6 128's for various items.
-
The real kick is going to be bandwidth, but given you are only allocated 1 GB of space, I dunno if that would matter, but for a high density site, neither the space or bandwidth would suffice. Personally I would rather pay $15/year for a 128M VPS with 20GB of space and 500GB of bandwidth, for something that your server would accommodate and have full root access, choose my own OS and yea, have full control. However, I am sure some people wouldn't mind the specs and would want maybe a CDN server. But really, there are VPS servers out there, that cost about the same and give you quite a bit more flexability etc. Just my 2 cents.
-
Yea, I would agree on the long term sessions. Which is why I generally list all active sessions for users and let them choose to kill the extra sessions or not. Different strokes for different folks
-
Nah, never disagreed. Just curious about it as I never heard of it being an issue. But the reasoning gave makes sense.
-
@xyph After doing some Brainstorming with Josh in IRC. I think I might get where you are going with this and may have just been mis-interpretation. If the site has a "Remember Me" feature, they generally store a cookie on the computer that authenticates the user. Just because the session was nulled, does not necessarily mean they are logged out. It just means that they will be re-authenticated via the cookie (again if they chose to use the remember feature) and a new session will be generated, meaning that they will not be logged out. So yea, I guess to say as long as there is a "Remember Me" option for cookie authentication, I think the regenerating the session for the user would be fine and acceptable. Apologies for me mis-interpreting your text.
-
<removed> One note: I beg to differ on this point completely. Especially with my mobile phone, if I were to be logged out of Gmail on my computer, because I logged in on it on my phone, that would be retarded. I had to enter a valid username and password to authenticate to my phone AS WELL as on my home computer. Why should either one kill the other's session? Both were authenticated just fine. If you are worried about session attackers, give the user a method to destroy all sessions associated to their account. Do not kill all valid and active sessions just because they login from another location. That is just stupid. And thinking about it, I do not even think my bank kills a session if I login from my phone and from my home computer at the same time. They are both valid sessions for my user as I proved authentication. So yea 1 session per user ever, is just a retarded ideology.
-
Well, in reality, that is up to the end user. As long as your end is safe, IE the authentication from SQL Injection remote inclusion, your code does what it should to protect the user, you cannot necessarily control what happens on their end. Depending on the site and how secure it needs to be, sure checking IP's and user-agents can be a good thing, such as my banking site. I would prefer them to kill my session upon a new IP as appose to not. If your site does checkout's where users can buy data, make them enter a password before they are allowed to process the order if one has not been entered in the past 15-20 minutes (or if the IP /UserAgent has changed like Amazon does). This would help prevent orders from going through when the user should not be placing orders. However, for a blog or forum type site, where nothing important is kept, that is way overkill. So as long as you do your part for the internal code, the user has to do their part by doing virus scans / trojan scans / malware scans. As this is where the majority of the hijacking will come from, their computer being infected. So showing them a list of "Active" sessions at the bottom of a page (or top) and allowing them to kill any session is good practice. IE say they were using a public computer at their school and forgot to logout, providing them a way to kill that session by logging in and doing so is a good feature. Other than that there is not much you can do, again that is their issue if they get infected with malware and someone takes over their account, the best you can do is provide them with a method to contact you incase of an incident and/or an method for them to kill any active session or regenerate their own session id.
-
I never heard of this, can you provide a link to the reasoning? I would love to give it a read.
-
Seriously? There are tons of legitimate reasons why an IP would change. 1: Connecting from a public network, sleeping your computer, connecting from home. 2: VPN connection, switching. I have multiple work VPN's and personal VPN's I switch to not to mention my home VPN as well. 3: Using a proxy for various reasons. 4: Connecting from your 3G/4G Mobile Broadband from somewhere. Not to mention I probably missed a few, but the IP and user-agent really do not matter as much as them having a valid session cookie setup. If they are valid for that session, leave it open. Update your IP logs, and perhaps show them to the user (like google does with Gmail) and allow them to kill the session for any unknown IP's. But don't just automatically kill them because an IP changes. I would stop using the site if they did that to me.
-
Why not just update the values? My IP changes quite a bit given I hop from VPN to VPN, if the session kept dieing on me I would be pretty pissed off. Updating the session should suffice. As for the user_agent, that should only change if the user is using an extension for the browser to change it. But I still would just update the session values, no need to regenerate it.
-
You should be able to assign a static IP with the router, if you have control. However: Listen *:80 Will work just fine.
-
Also a word of caution, you should either make it .inc.php or set the .inc to be disallowed in the .htaccess with something like: <Files ~ "\.(inc)$"> order allow,deny deny from all </Files> So that way people cannot just look at your php code.