.josh

Sorry for the inconvenience. I've written quite a lot of TL;DR's in my time and have managed to reach the limit once or twice in a blue moon, for my extra special book-length soap box rants..so I have to wonder what could have possibly motivated you to write a novel to someone, being new on a forum... Anyways.. I never endeavored to find out what the exact limit was... I don't know what IPB's character limit is for PMs/Posts.. I don't see anything in the Admin CP that shows or sets this, so it looks like it's a limit imposed internally within the IPB code. I'm not particularly inclined to go rummaging through IPB's code, so I suggest you ask on the IPB forums (we just use their software.. we aren't affiliated with them or anything).

The closing quote around the href="..." value. Right before class="..."

right.. but the problem is with proving and enforcing it.

It's gonna be a "risk" no matter what. Even if someone signs a non-compete, who's to say they won't pass your code off to someone else for a buck, and that 3rd party signed nothing. And even if you cover restriction of that sort of thing, you'd have to prove it. The bottom line is it's really hard to prove someone outright stole your stuff, and it's really hard to enforce or even define "rights" for this sort of stuff. And that's just dealing with the law within your own country's jurisdiction. For instance, lets say you're in the US. Doesn't matter if you have a bullet proof copyright on something.. someone from some other country can swipe it and host it on some host outside of the US.. there's little to nothing most people can do about that sort of thing. Even people who have a LOT of money and legal resources to pursue it have a hard time doing something about it. Just take a look at all the big name software and media companies constantly throwing millions and billions of dollars at protecting against piracy and look at how effective they really are at it. Bottom line is "closed source" stuff is out-dated and not a viable method these days. This is why a lot of software these days gravitate towards some sort of open-source license, and focus on providing services/support, rather than just trying to sell a product.

use strlen for your condition and a dot . to concatenate strings.

you only want it to pop if an if statement in php is true? js cannot directly run php. you're going to have to a) determine whether true or false before the page load and output a js var to check b) do an ajax call to run the php code and return a result.

I supplied a link in my previous post that explains why you should avoid regex for html. I labeled it "DOM Parser" because the link also gives suggestions for DOM Parsers you can use. http://forums.phpfreaks.com/topic/273123-readme-php-regex-resources-faqs/?do=findComment&comment=1405513

Extracting "sentences" is complex and imperfect enough. It would be better to leave your current regex alone and do a 2nd filter. // do the sentence matching preg_match_all('/(?<=[.?!]|^).*?(?=([.?!])\s{0,3}[A-Z]|$)/s',$content,$matches); // wrap search term in preg_quote if you are accepting arbitrary data, so as to escape special regex chars $search = preg_quote('foobar','~'); // return sentences that have $search in it. remove the "i" modifier if you want it to be case-sensitive $sentences = preg_grep('~'.$search.'~i',$matches[0]);

well there's certainly outdated code in there but the problem is definitely the mail call. No, it does not send an email from the actual email account. So if you were to put "iheartart@phpreaks.com" into your "From: " field in your form, your server isn't going to log on to our server and send it from that email address. Your server is going to send it from itself, because it's the email server. And it has your own domain(s) tied to it, just like our email server has phpfreaks.com domain tied to it. So therein lies the problem. Your email server, which is located on yoursite.com, is trying to send an email claiming its from somewhereelse.com. You can make an email claim it's from anywhere or anybody. That's easy. That's exactly what your script does. The problem with that is whether or not your email server will allow you to do it (which according to the error message, it won't), or whether the recipient server will outright deny it, or accept it but mark as spam or legit. For example, if you try to send an email from yoursite.com to a someone@gmail.com, but claim it's from you@someothersite.com instead of you@yoursite.com.. well gmail sees that your email server that is located on yoursite.com is trying to send an email claiming it's coming from someothersite.com. Now, gmail may decide to put it into someone@gmail.com's mailbox nonetheless. It boils down to whether or not it decides the email is spam. But claiming an email is from a domain that doesn't match the domain the email really came from is a really good way to get on a spam list and get your email server blacklisted. This is something that hosts generally want to avoid, especially hosts running shared servers. Think about it. If someone else is using the same host as you and you're both on the same shared server, that means you're also sharing email servers. Now lets say that asshole starts sending emails out, spoofing who they are from. This doesn't just get yoursite.com's domain put on spam blacklists. This usually also gets the host's email server put on the black list, and any other domains that email sent emails for. That means if some asshole sharing the same shared host as you starts a spam operation and your host lets it through, it may result in your site's emails being blacklisted as spam. You don't want some other random asshole customer doing this and affecting your site, do you? No. And neither does your host, because then people stop hosting their sites with them. Which is why hosts will usually always put settings on their mail server to reject attempts to send emails out that don't match the domain of your site. This is probably why your scripts suddenly stopped working. In the past, your host didn't have the email server setup to reject this. But they more than likely got flagged as a spam server, and so they put the measure in place to prevent it. So, I was not joking when I said earlier that it could have been because of your site having a script on it that allows for people to invoke mail calls claiming to be from a domain other than your site. Maybe not directly your site.. depends on how much traffic and emails you are getting. More likely scenario is some spam operation came upon your site and figured out through your scripts that the host didn't check for that shit and then they signed up for a hosting plan and went to town. Now, it seems to me from looking at your script, that the intention of your script is to have someone fill out a form that provides contact info and interest(s) or whatever, and then that email gets sent to you, as a lead or whatever. And this script is using the email address the person puts into the form as the "From: " address, for no good reason. There's literally no good reason for this, and every bad reason in the world for this. Obviously you want to know the visitor's email address, but it should be included as info in your email body (which it already is), but not as the person the email is coming from. Just hardcode the "From: " header to your site's main email address. Or just remove the "From: " header altogether and let the mail server use its own default, and your problem should be solved. But I'd look to update this script or find an updated one or hire someone to update it or w/e on top of that, regardless, because it is outdated, full of deprecated stuff. And honestly, if your host has gone this long and has only just not gotten around to disallowing it.. you should probably think about switching hosts; something like this is like.. Shared Hosting 101, so only God knows what other kinds of bad config and practices may be going on behind the curtains.

well, wait a minute.. what are you attempting to use in $email_from? It sounds like you are attempting to use a "From: " email address that doesn't match your server/domain and the email server settings are (rightfully) setup to not allow that. It is unlikely that your host will change the email server config to allow this. In fact, if you are using From: email addresses that don't match, there's a very good chance your host changed the email config because of you, and frankly I'm surprised you have not received notification about it. But if you are indeed using a "From: " email address that matches your domain, then yeah, contact your host.

yes, contact your host.

So your other code still sends mail fine? If so then i suggest you compare this code to your other code. If not then.. well, you didn't touch those other forms and they stopped working, so contact your host.

one thing you can check is step 1) turn on error reporting. Put this at the top of the file that makes the mail() call: ini_set('display_errors',1); ini_set('display_startup_errors',1); error_reporting(-1); step 2) remove the error suppression from your mail call (remove the @) mail($email_to, $email_subject, $email_message, $headers); step 3) comment out the redirect stuff //header("Location: $thankyou"); ?> <script>//location.replace('<?php echo $thankyou;?>')</script> Now go through your form process and see if any errors are output. This may or may not produce something that will give you a clue.

The code wouldn't randomly stop working if nothing changed. If you are absolutely certain that you made no changes to any of your files, then contact your host and take it up with them. They must have made changes on the server that has affected your code. It could be any number of things like upgrading or changing their email server and improperly configuring it or updating php config file accordingly. They could have upgraded php and maybe something in your code no longer works. Or a million other things.

actually wait.. you said you need to be able to decrypt it to show plaintext version.. so mcrypt functions are as good as any.. This comment has an easy straight-forward class for it. I guess.. your funeral.

In any case, if you are somehow confident or are otherwise not deterred by any liabilities you may impose on yourself.. use password. If the server is not on php v5.5.0+ yet, there is an alternative. If you still don't meet the php v5.3 req for that, then.. I mean if you're really really confident in not being held liable..lol just md5 or sha1 it up.

man.. again.. take it for what it's worth.. but I have a sneaking suspicion no amount of words in a contract will be bulletproof against the hordes of angry lawyers released on you by angry social media sites and other big name businesses if whatever you do is hacked. If it were me, I'd tell them hell no I'm not doing it, even if it cost me my job. I know that's a lot easier to say when I'm not in your position, but I just couldn't take that risk regardless.

oh dear.. i wouldn't touch that liability with a 100ft pole.. there are plenty of "universal pw storage" programs out there that are on the client's computer, and that's where it should be. I guess the only "help" that statement offers is I'd strongly recommend you try your very hardest to push back on this or otherwise remove yourself from it.. cuz.. that is a huge liability.

Alternatively, you can use preg_replace_callback. However.. this would be better achieved with a DOM parser. For shits and grins, here is the preg_replace_callback version: $string=<<<EOC <li id="5691_3" value="pass"> Some text here</li> <li id="5691_4" value="pass"> Some text here</li> <li id="5691_6"> Some text here</li> <li id="5691_7" value="fail"> Some text here</li> EOC; $string = preg_replace_callback( '~<li[^>]*(id="[^"]+")(?:[^>]*value="([^"]+)")?[^>]*>(.*?)</li>~', function ($m) { $r = "<br>Result for {$m[1]} - "; $r.= (!empty($m[2]))? "You {$m[2]}ed!" : "It's blank!"; $r.= " {$m[3]}"; return $r; }, $string ); echo $string; I too will decline making this "fool proof" as far as order of attributes, spacing, etc.. because as I said, a DOM parser is better suited for this sort of thing.

you need to be more specific about what tags you want to keep and what tags you want to toss. "toss the paragraph tag but leave the html tags such as bold..." well they are ALL html tags. Also, there are several ways that last part can be bolded. You need to show actual content, a "before" and "after" picture (the viewsource, not the rendered), and exactly what tags you want to keep and toss. "Such as.." is vague.

you can click the "Mark Solved" button on the bottom right of someone's post if you feel your question was resolved.

I haven't used komodo editor but doing a quick 1m glance at their site it looks like it's just an editor, doesn't have a server and php built into it to actually evaluate php code. As davidannis said, look into using something like WAMP or XAMPP. Komodo may even have a way in its settings to point to one of those for preview once they are installed (but I'll leave that research up to you)

looks to me like your server isn't setup to parse your file extension as a php file. When a file is requested, the server doesn't automatically go through the file looking for relevant script tags to parse. You must set it up to run it through things like php or perl or w/e based on the file extension. For example, if that code is in like somefile.html (I did not download your zip to look), the server's default settings are not setup to run an html file through the php interpreter.

test.php <?php echo "from test.php"; print_r($_SERVER); include('test2.php'); ?> test2.php <?php echo "from test2.php"; print_r($_SERVER); ?> both print_r($_SERVER) will show: Array ( [SCRIPT_FILENAME] => /path/to/script/test.php [REQUEST_URI] => /test.php [SCRIPT_NAME] => /test.php [PHP_SELF] => /test.php )

so where/how are you setting $_id and $category_id