Coding Php Mysql Mutasi Pegawai

1. Php Mysql Tutorial Pdf

Cara Membuat Aplikasi Penggajian dengan PHP dan MySQL - Koding Data Kehadiran Pegawai (Bagian 2). Bahwa coding sangat menakjubkan sehingga bisa mengubah.

I would really like to see a simplified forum that is standards compliant. So many of the popular packages seem to add 'features' just for the sake of adding them. It would be cool to have something that was really basic to start with, then extra features could be added in.I'm working on a lot of customizations on vBulletin and the amount of interface clutter really annoys me. Things like post icons, all the editing controls on the posting messages which nobody ever uses, buddy/ignore lists (which are very rearely used), subscriptions (only useful in really big forums), even private messaging could all be add-ons instead of integrated by default.With a nice clean, standards-compliant, CSS-based layout your adaptability would aslo improve. People could modify the layout however they wanted instead of being contstrained by endless nested tables and crap.You could have a pricing model where the basic forum was very cheap or even free, then add ons could be purchased for a small additional price. That would be cool.

I would really like to see a simplified forum that is standards compliant. So many of the popular packages seem to add 'features' just for the sake of adding them. It would be cool to have something that was really basic to start with, then extra features could be added in.I'm working on a lot of customizations on vBulletin and the amount of interface clutter really annoys me. Things like post icons, all the editing controls on the posting messages which nobody ever uses, buddy/ignore lists (which are very rearely used), subscriptions (only useful in really big forums), even private messaging could all be add-ons instead of integrated by default.With a nice clean, standards-compliant, CSS-based layout your adaptability would aslo improve. People could modify the layout however they wanted instead of being contstrained by endless nested tables and crap. Somebody mentioned that you shouldn't constrain yourself to mysql. If you're doing it for yourself, why constrain yourself to php?

I don't mean to sound like I'm trying to sound smart by praising all the new buzzwords, but before you start, check out the alternaties. There are some really great frameworks for Ruby and Python now that are much easier to use than PHP.I built a forum using Ruby and Ruby on Rails in two days. It doesn't have to take years. I understand that php/mysql is supported everywhere and all, but if you are coding for yourself, you don't need to care about the servers everybody else uses.That said, I really think you should go for it. I don't see the use of half the functions that come with vBulletin and IPB and whatnot. Somebody mentioned that you shouldn't constrain yourself to mysql. If you're doing it for yourself, why constrain yourself to php?

I don't mean to sound like I'm trying to sound smart by praising all the new buzzwords, but before you start, check out the alternaties. There are some really great frameworks for Ruby and Python now that are much easier to use than PHP.I built a forum using Ruby and Ruby on Rails in two days. It doesn't have to take years. I understand that php/mysql is supported everywhere and all, but if you are coding for yourself, you don't need to care about the servers everybody else uses.That said, I really think you should go for it. I don't see the use of half the functions that come with vBulletin and IPB and whatnot.

The one thing I can't wrap my mind around is this; How long will it take to code a forum from scratch? What is your time worth? How much is it to buy forum software that is already proven functional and can be extended any which way you want it?Perhaps I am biased as time is very precious to me, but I just can't see that coding a forum from scratch is a good use of anyone's time. I don't see the benefit to the Internet community at large either. If anything then mods of current forum products would be welcomed and appreciated (even through donations) by many.

The great 'PHP and MySQL coding tips' thread has been restructured. The posts from the thread=54074old thread/thread have been sorted into four categories and are quoted below, with a link to the original post. Not all posts have been quoted.Before you create a new tip, please make sure it's not already in here.Please do not create fluff posts.

Instead of a thank you post here, send the person a Private Message (PM).It is Falesh that has done the heavy work here pulling the original thread apart. We would like to say a really big thank you for doing it. Send him a url=and say thanks! DRLaRRYPEpPeR said:Strings1) As a finesse thing, I use single quotes around strings whenever possible (e.g. Strings that don't contain variables, single quotes, etc.).

This is supposed to make less work for the PHP parser.2) When an array variable isn't in a string, put quotes around string-literal keys so they are not regarded as constants:`php// OKecho $row$key;// Wrong, unless key is a constantecho $rowkey;// Rightecho $row'key';// OK, since it's in a stringecho 'Text: $rowkey';`3) Remember, you can break out of PHP mode for large sections of HTML. This is faster than echo'ing and you don't need to escape quotes. Anguz said:to echo big chunks of html with vars in the middle using single quotes, instead of double quotes (slower) or jumping in and out of php, even if using shorthand, I do it like thisphpecho 'Hello,My name is ',$name,' ',$lastname,' and am ',$age,' years old.I live in ',$city,', ',$country,' since I was born.You can contact me at ',$email,' or by phone at ',$phone,'Regards,',$name,' ',$lastname,';it's very shorthand and fast.

It can be very comfortable to use in a simple php template system. Louism said:Consider using strreplace instead of the pregreplace or eregreplace functions.

The only reason why you would use pregreplace or eregreplace functions would be that you REALLY need to use regular expressions. Also, as of PHP 4.0.5, every parameter in strreplace can be an array, so theres no excuse to use preg or ereg fucntions when replacing simpel strings anymore.A useful use of strreplace:`php$string='The quick brown fox jumps over the lazy dog.' ;$patterns0 = 'quick';$patterns1 = 'brown';$patterns2 = 'fox';$replacements0 = 'slow';$replacements1 = 'black';$replacements2 = 'bear';$string=strreplace($patterns, $replacements, $string);//$string='The slow black bear jumps over the lazy dog.' DRLaRRYPEpPeR said:ereg vs pregWhen it comes to the regular expression functions, ereg.

and preg., the preg functions are the clear choice. The preg functions are generally twice as fast as their ereg counterpart. They also support more advanced regular expression operations. I can't think of any reason why you would need to use the ereg functions.preg manual page and url=syntax((long and confusing but pretty good). Falesh said:Here's a bit of code I use to change new lines into XHTML 's and 's.`php// the first bit is to make both 'r' and 'r' line endings into '$string = strreplace('r', ', $string);$string = strreplace('r', ', $string);// this next bit first adds an openingthen makes all double line breaks into$string = '.strreplace(', ', $string);// finally this turns any single line breaks into's and closes the last$string = strreplace(', ', $string).'

DRLaRRYPEpPeR said:Quotes around numeric data in queriesFor numeric columns in MySQL, you shouldn't put quotes around any of their values in queries. As our resident database guru, MattR, says, 'that is very non-standard and will only work on MySQL.' But if it's unknown data, how do you know that it's numeric and not letters that will cause an error? You can make sure that only a number is used in the query by first type-casting the data as int (or float for decimal numbers):`php// If id is being passed in the URL$id = (int) $GET'id';$r = mysqlquery('SELECT. FROM table WHERE id=$id');`Then even if id is set to 'abc,' the worst that can happen is a 0 will be used in the query. No quotes; no error.Column types and attributes1) Be familiar with MySQL's column types along with their ranges/lengths.

You should use the smallest column type that will hold the data that you expect to store. Most of the time, you probably don't need INT, because MEDIUMINT, SMALLINT, or TINYINT have enough range. Using a smaller type saves space and speeds things up.2) Declare all of your columns NOT NULL unless you need to store NULL values (NULL is not the same as 0 or the empty string). If you need to store NULL, you'll know. Again, NOT NULL saves space and speeds things up.3) Making INT-family columns UNSIGNED will effectively double the positive range with the same storage requirement. For example, TINYINT's highest value is 127. TINYINT UNSIGNED's highest value is 255.Indexes and optimization1) First, I sometimes see people create tables like this:CREATE TABLE table (id INT UNSIGNED NOT NULL AUTOINCREMENT.KEY (id),UNIQUE (id),PRIMARY KEY (id))Do not make a column KEY, UNIQUE, and PRIMARY KEY.

In this case, KEY and UNIQUE don't help anything. The PRIMARY KEY is a key and it is unique. By specifying 3 indexes, it wastes space and slows down write operations.2) Indexes/keys are the key (no pun intended) to fast queries ( especially joins).

The 3 types of indexes are PRIMARY, UNIQUE, and KEY/INDEX (same thing). It's hard to explain when and how to use indexes, so I'll just point you to some relevant pages in the MySQL manual: Speed of SELECT queries and How MySQL uses indexes.3) When you have your indexes setup, use EXPLAIN on SELECT queries to make sure your indexes are actually being used.

Voostind said:MySQL column typesIt is not true that using the smallest column type possible leads to query results. Thereason is that, internally, MySQL uses 32-bit integers for indexes. (At least, last time Ichecked it did.) So when you build an index on an integer-type like SMALLINT or TINYINT,it will still become a 32-bit integer in the accompanying index (possibly even resultingin worse performance when running queries!). There even was a time MySQL messed up indexeson integer columns that weren't 32-bit, but this probably isn't true anymore.

(I don't useMySQL myself.) Of course it makes good sense to use smaller integer types that aren'tindexed and have a limited range, like someone's age.Another reason for not using anything other than the default INT32 (INT INT32) is thatother software might not understand it. If, for example, you use an ODBC connection to aMySQL database, you should only use simple data types. Microsoft Access in particular,which is used a lot for these kind of things, will freak out otherwise.Declaring columns NULL or NOT NULL has nothing to do with optimization! It has todo with the design of the database. If some table can have empty fields (as specified inthe design), it should be NULL, and not 0 or the empty string.

This way, when some fieldholds the value 0 (or the empty string), you'll know it's not an empty field. It's a fieldthat has an empty value, which is something quite different.Indexes and optimizationsOf course you shouldn't define a single field as KEY, UNIQUE and PRIMARY KEY at the sametime. But frankly I'm surprised that MySQL doesn't optimize this away. As soon as somefield is already a PRIMARY KEY, it needn't create two additional indexes. Are you sureMySQL doesn't notice this?

(If so, it's even more stupid than I thought.). Redemption said:as for declaring fields NOT NULL when you know the field is never gonna be NULL, i think you missed DoctorLarryPepper's point. posted by the docDeclare all of your columns NOT NULL unless you need to store NULL values (NULL is not the same as 0 or the empty string). If you need to store NULL, you'll know.declaring a column NOT NULL saves 1 byte (or 1 bit, i forget.

Set me right on this). That optimizes use of the memory used to store the fields.

It makes a difference when you've a thousand record table. Voostind said:as for declaring fields NOT NULL when you know the field is never gonna be NULL, i thinkyou missed DoctorLarryPepper's point.Yep. I competely overlooked.

Php Mysql Tutorial Pdf

Sorry! declaring a column NOT NULL saves 1 byte (or 1 bit, i forget. Set me right on this).that optimizes use of the memory used to store the fields. It makes a difference whenyou've a thousand record tableLOL!

Even when it's one byte, it wouldn't matter! Thousands times 1 byte is 1,000 bytes is(officially) not even 1 kB! On one million records it would save less than 1 MB. Only in really, really large databases it matters, but then storage is not likelyto be much of a problem. Redemption said:Originally posted by voostindLOL!

Even when it's one byte, it wouldn't matter! Thousands times 1 byte is 1,000 bytes is(officially) not even 1 kB! On one million records it would save less than 1 MB.

Only in really, really large databases it matters, but then storage is not likelyto be much of a problem.yeah but programmers usually like to optimize everything. The doc is one of them and so am i (most times. When i'm not lazy). And well actually it saves 1 byte or 1 bit (??) for each field. There're bound to be plenty of records and thus almost exponentially more fields.there's a better explanation for this NOT NULL thing. I read it somewhere but i forget.

Oh well, let the doc defend himself when he comes back. DRLaRRYPEpPeR said:most of the time you don't need to store NULL values in MySQL. 0 or the empty string works fine. For example, with an email column, if someone doesn't enter an email address, just store the empty string.

I can't see any need for NULL.one column i do have NULL is an age column. If an age isn't entered, i store NULL, rather than 0. That way, in case i want to do something like SELECT AVG(age) FROM., only the people who have an age will be averaged because the grouping functions (except COUNT(.)) ignore NULL rows.

If i had instead stored 0's, those rows would lower the average.don't use NOT NULL IF you need to tell the difference between an empty value (0 or empty string) and no value (NULL). Originally posted by voostindMySQL column typesIt is not true that using the smallest column type possible leads to query results. Thereason is that, internally, MySQL uses 32-bit integers for indexes. (At least, last time Ichecked it did.) So when you build an index on an integer-type like SMALLINT or TINYINT,it will still become a 32-bit integer in the accompanying index (possibly even resultingin worse performance when running queries!).

There even was a time MySQL messed up indexeson integer columns that weren't 32-bit, but this probably isn't true anymore. (I don't useMySQL myself.) Of course it makes good sense to use smaller integer types that aren'tindexed and have a limited range, like someone's age.Declaring columns NULL or NOT NULL has nothing to do with optimization! It has todo with the design of the database. If some table can have empty fields (as specified inthe design), it should be NULL, and not 0 or the empty string.

This way, when some fieldholds the value 0 (or the empty string), you'll know it's not an empty field. It's a fieldthat has an empty value, which is something quite different.i got my information from the MySQL manual. From: One of the most basic optimisation is to get your data (and indexes) to take as little space on the disk (and in memory) as possible. This can give huge improvements because disk reads are faster and normally less main memory will be used. Indexing also takes less resources if done on smaller columns.Use the most efficient (smallest) types possible.

MySQL has many specialised types that save disk space and memory.Use the smaller integer types if possible to get smaller tables. For example, MEDIUMINT is often better than INT.Declare columns to be NOT NULL if possible. It makes everything faster and you save one bit per column. Note that if you really need NULL in your application you should definitely use it. Just avoid having it on all columns by default.only the index pointers (is that what they're called?) are 32-bit.

I just checked and changing a SMALLINT column to INT on an 880 row table increased the size of the index file. So obviously SMALLINT takes up less space in the index.it's even more important to use smaller types, when possible, on indexed columns.

They can be compared faster when doing joins and other searches. And by being smaller, they not only save disk space, but require less disk reads/writes and allow more of the index to be kept in the keybuffer (if it's a large table and assuming the table stays in the tablecache, otherwise its index blocks are released from the keybuffer). The more things you can keep in memory, the less disk access you have. But you know that.declaring columns NOT NULL does have something to to with optimization. I'm not sure what the manual means by 'you save one bit per column.'

I just checked on the 880 row table. Removing NOT NULL (from one column) made the data file 840 bytes larger. So that looks more like 1 byte per row. Of course the savings are multiplied for each column you make NOT NULL.when columns are NOT NULL, that's one less value to check for. Some examples of where NOT NULL helps:mysql EXPLAIN SELECT. FROM table WHERE notnullcol IS NULL;+-+ Comment +-+ Impossible WHERE noticed after reading const tables +-+MySQL doesn't need to check the table because notnullcol can't possibly contain a NULL row.also, MySQL can do optimizations on things like.

LEFT JOIN t2 ON t1.col=t2.col WHERE t2.col IS NULL. In the manual, for, it says this for a value in the Extra column: Extra.Not existsMySQL was able to do a LEFT JOIN optimisation on the query and will not examine more rows in this table for the previous row combination after it finds one row that matches the LEFT JOIN criteria. Here is an example for this:SELECT. FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL;Assume that t2.id is defined with NOT NULL. In this case MySQL will scan t1 and look up the rows in t2 through t1.id. If MySQL finds a matching row in t2, it knows that t2.id can never be NULL, and will not scan through the rest of the rows in t2 that has the same id. In other words, for each row in t1, MySQL only needs to do a single lookup in t2, independent of how many matching rows there are in t2.

Another reason for not using anything other than the default INT32 (INT INT32) is thatother software might not understand it. If, for example, you use an ODBC connection to aMySQL database, you should only use simple data types. Microsoft Access in particular,which is used a lot for these kind of things, will freak out otherwise.i'm aware of that. I don't know if it's an issue for most people, though.

If it is, they'll probably know. Of course you shouldn't define a single field as KEY, UNIQUE and PRIMARY KEY at the sametime. But frankly I'm surprised that MySQL doesn't optimize this away. As soon as somefield is already a PRIMARY KEY, it needn't create two additional indexes. Are you sureMySQL doesn't notice this? (If so, it's even more stupid than I thought.)it seems to be pretty stupid.

When you do a SHOW INDEX FROM table, it shows 3 indexes.:disagree: i too thought it might ignore the KEY and UNIQUE. Egghead said:Databases and TablesWhen putting SQL queries into your PHP scripts, you should create a seperate file which sets the names of each database or table. This file can then be included when required, and if any database or table name needs to be changed, then you only need to make one alteration - not many!

This is very useful when you are using scripts from other people which create databases/tables, as their script may create a new database/table with the same name as one you already have.Example configuration file:`php// Database Table Names$conf'tbl'books' = 'booknames';$conf'tbl'authors' = 'writers';Any query can then use the defined names as so:PHP Code:$table = '$conf'tbl'books';$field = 'fieldvalue'$sql = 'UPDATE '. SET myfield = '. ';// Note: a backslash is missing here!' $table = '$conf'tbl'authors';$field = 'fieldvalue'$sql = 'UPDATE '. SET myfield = '. ';// Note: a backslash is missing here!`NOTE: The VB Code in this forum keeps removing a backslash from the PHP source code.All lines reading' ' ';should in fact read' ' '. DRLaRRYPEpPeR said:First and foremost, I believe, is the use of registerglobals.

For those of you who don't know, registerglobals allows you to access variables from forms and URLs (such as file.php?var=foo) as $var in your script - 'magically' created global variables. Unfortunately, this old method continues to be used in most tutorials/examples.

The PHP developers seem to have realized that registerglobals was a bad idea, though. They discuss in the PHP manual and recommend turning them off in php.ini::Note that registerglobals is going to be deprecated (i.e., turned off by default) in the next version of PHP, because it often leads to security bugs.You should do your best to write your scripts so that they do not require registerglobals to be onIn fact, as of PHP 4.2.0, registerglobals is now off by default on new PHP installations. By writing code that relies on registerglobals being on, you risk having that code not work on some systems! Wouldn't you rather use the preferred method of accessing variables and have your code work on all PHP installations?The proper way to access these variables is via their respective arrays. So instead of $var, in the above example, you should use $ GET'var'. Similarly, use $SERVER'HTTPUSERAGENT' instead of just $HTTPUSERAGENT.The main arrays are $ GET, $POST, $ COOKIE, and $SERVER, depending on where the variable came from, obviously. You can read more about them, and a couple of others, here and url=in the manual.Please access your variables via these arrays!securityabout the security stuff.

When registerglobals is off, it doesn't matter how many variables a hacker tries to add in the URL/form/cookie, they will stay in the $. arrays doing no harm unless you access them. When registerglobals is on or you extract the arrays, any variable that is supplied will be in your script, even though you never expected it to be. However, as i said, when they're in the arrays, they'll never affect anything! It's OK to do$id = $GET'id'and i do all the time, because YOU are creating the $id variable, and you know it's from the URL since it's in the $ GET array. Again though, if registerglobals is on or the arrays are extracted, and you never used $id in your script, it would be created if `id=' was put in the URL.

That's exactly what i don't want.i hate that these global variables were ever created. It's just wrong IMO to not know where user variables came from. They should be confined to something like an array to keep them harmless; and they are when registerglobals is off and you access them via these arrays - the way, and only way, it should've been all along. McGruff said:Security with registerglobalsI'm not sure if it's good to recommend EALL & ENOTICE though - although I note you only say this is a minimum.& ENOTICE doesn't catch undefined variable/index errors, which can be a big security risk with reg globs on (in a shared environment you might be stuck with that).If a hacker has bombarded your script with a bunch of vars which are declared with reg globs there are three options.One: these variables aren't native to your script. They sit around doing nothing.Two: the hacker has guessed some valid var names and his hacked vars are declared right at the start of the script.

A few lines down, the script declares your own values for the vars, overwriting the hacked values. Once again, they do nothing.Three: you have undefined vars/indexes. You're porked.Always EALL for development. HarryF said:Globals appear to make your life alot easier. But do not succumb to them!The downside of globals is they make code extremely hard to read and understand, particularily with large scripts or where you're including files or using classes. One day you're going to declare the wrong variable as global, and be condemned to purgatory, destined to spend the rest of your days debugging the same piece of code.In general, it's a good habit to start early, and only use globabls for things like a select few enviroment variables (such as $PHPSELF and $SERVER), if you're going to use them at all.Of course the real PHP Monks say:NEVER USE GLOBALS!Remember, globals, like magicquotes ARE EVIL!

Voostind said:For things such as '$isloggedin,' then yes, I agree that global vars are evil. On the other hand, if you look at phpBB's code, the use global vars for internal variables such as 'global $db.' In this case, $db is a database abstraction layer that that entire project uses.So you're saying in some cases it's okay to use globals. Well, it's not (IMHO). The fact that a program uses globals can never be rectified by the reason for using them, as far as I'm concerned.

So in this case I'd say: phpBB has a design problem, because it has to have at least one global variable to work properly. HarryF said:Use sessions for users currently actively browsing your website. Sessions are there to store data that's required for the users current visit. For example storing their username / password for your sites authentication system.Use cookies for long term data which you want to survice between visits by an individual users. For example you store their name in a cookie so that next time they come to your site, you can display 'Welcome back HarryF!' The cookies would then 'hand off' their data to the sessions for the current visit.

Falesh said:Try using a text editor that lets you navigate to functions.I found this when using (a free text editor). I had just put all my functions into a separate file and then found that if you select the Plugins menu, then Function List and click View List it brings up a box with a list of all the function names in the file. If you click on a function name it moves you to the start of that function.This has been a revelation to me for moving around my code and keeping my head around what functions I have.

My tip (I noticed nobody ever wrote this in any articles anywhere which gave me lots of problems until I found it out my self):When using mysqlrealescapestring or addslashes it changes ' and ' to ' and ' which we all know, right? But when adding the variables to the mysql database it doesnt actually put the backslashes into the table.

You DONT need to use strip slashes when bringing data out of the table because the backslashes arent added!Probably sounds like I'm stupid, but there is not one article that I learned from which told me 'the backslashes arent actually added to the database'. This might have been mentioned before, but I didn't see it. Anyways, it's a small performance increase trick - unnoticeable in 99% of the cases, but could make a bit of difference in very large apps. Echo actually takes parameters, unlike print, which means if you are using it to print out strings and variables, you don't have to concatenate, you can do it like this:echo 'Hi, my name is ', $name, ' and I live in ', $town, '.' ;Which is actually just a tid bit faster than using.construed from the php manual. Here's how to insert an UNIX timestamp into MySQL.

I learned it yesterday:$date = $time // This produces an UNIX timestamp$sql = 'INSERT INTO table (column) VALUES (FROMUNIXTIME($date))'; // And this is a query you need to runThis is probably trivial to most of you but I was very surprised to find out about this approach. Until yesterday I have been keeping date and time information in database just as strings.In addition, here is how to select an UNIX timestamp from a database:$sql = 'SELECT UNIXTIMESTAMP(column) FROM table WHERE.' ; // You need to run this query.

The most important tip any PHP beginner must have is: to turn the error reporting on when developing script. Putting this single lineerrorreporting(EALL);at the top of your code is a life-savier.When error reporting is not on, PHP masks many warnings that could potentially bring down your application, and when that happens, it is hard to find the problems which are often misspelt variables and variables that have not been set or not available in that part of the code.Equally impotant is that you take the error reporting off when you put your code in a live website.Hope that helps somebody.Rageh. Email & HotmailIf you are having trouble with sending email with mail to hotmail, then please try the following:. Log into your Cpanel and open your webmail (you will need an email account thats been created in the Cpanel), create and send an email to your hotmail account. If no email arrives (and it's fairly quick) then it's your hotmail account. Open your hotmail account through your web browser.

Mine has the 'Options' tab on the right handside, click that to reveal the drop down menu. The last tab is another link called 'More Options', click this to open up another page. Under the heading 'Junk E-mail' click onto the link 'Filters and reporting', now choose 'Standard' (if it's not already chosen) under the junk e-mail filter heading. Now try again to send an email through your webmail account.If the above fails, try the lower setting in your junk e-mail filter, other than that it will tell you if your ip address for your website is blocked, it's at this point to contact the webhost. Single or Double quotes for strings?Here are the results of combing through the top ten search results for, as they apply to quoting strings.When a string is literal (contains no variable substitutions), the apostrophe or 'single quote' should always be used to demarcate the string.no preference.For PHP, i'd suggest to follow Zends suggestions as in #1.When a string is literal (contains no variable substitutions), the apostrophe or 'single quote' should always be used to demarcate the string.no preference.unrelated.Drupal does not have a hard standard for the use of single quotes vs. Double quotes.

Where possible, keep consistency within each module, and respect the personal style of other developers.With that caveat in mind: single quote strings are known to be faster because the parser doesn't have to look for in-line variables. Their use is recommended except in two cases:. In-line variable usage, e.g. '$header'.

Translated strings where one can avoid escaping single quotes by enclosing the string in double quotes. One such string would be 'He's a good person.' It would be 'He's a good person.' With single quotes. Such escaping may not be handled properly by.pot file generators for text translation, and it's also somewhat awkward to read.Coding Style - Developers should use the PEAR coding standards as the coding style reference in CartoWeb which state Things like 'single quotes vs double quotes' are features of PHP itself to make programming easier and there are no reasons not use one way in preference to another.

Such best practices are left solely on developer to decide.no preference.Strings in PHP can either be quoted with single quotes (') or double quotes ('). The difference between the two is that the parser will use variable-interpolation in double-quoted strings, but not with single-quoted strings. So if your string contains no variables, use single quotes and save the parser the trouble of attempting to interpolate the string for variablesSummaryPrefer single quotes: Zend, Stack Overflow, orangeHRM, Drupal, EvoltNo preference: Dagblato, Pear, Cartoweb, TuVinhPrefer double quotes: none. Sending values to the database is fraught with issues, but if you ensure that your database values are escaped only once, you should be safe. The appropriate ways to do that are to use mysqlrealescapestring at the database query itself, as in the example on the mysqlrealescapestring documentation page, or by using prepared statements with for example, url='Output to the pageFunctions such as htmlspecialchars and url='are useful for outputting values to the page.

The former only converts ampersands, double quotes and angled brackets, which provides a useful minimum of protection. The latter function converts every single character that has an html entity equivalent, which can sometimes be considered to be too heavy-handed.echo 'An email has been sent to you at '.'