gizmola

So you want a 2nd array? $colors = array("red hello","green this","blue lovely","yellow morning"); $firstwords = array(); $lastwords = array(); foreach ($colors as $val) { list($firstwords[], $lastwords[]) = explode(' ', $val); } print_r($firstwords); print_r($lastwords); Output is: Array ( [0] => red [1] => green [2] => blue [3] => yellow ) Array ( [0] => hello [1] => this [2] => lovely [3] => morning )

As I said, the information is still good. Whether or not you use '==' or '===' is situational. It's not like '==' is deprecated. The important thing is to understand is when using '===' will evaluate as FALSE. I don't use '===' unless I absolutely require it, because the nature of PHP is to be loosely typed and to intrinsically typecast variables in the way you typically want them to be typecast. As for a project -- I find that the best one will be the one you come up with, where you attempt to build something that interests you. Many years ago, I had a webcam sitting in the window of my house, so I wrote some scripts that did things like assemble up groups of stills it took into mosaics. Whatever area interests you, is going to be the one that leads you into a DIY project where you can apply what you've learned, and invariably it will teach you much more than something canned, because you will have to problem solve, which is what real programming is actually about. You can mix and match functions and objects in projects however you like. Once you are clear on the underlying concepts, you should be able to figure out how to create a function library to support that project. At its simplest, concentrate on making simple discreet functions that do one thing. Try and organize said functions into one or more php scripts that you will include in your main script. So you don't get bogged down, just put them in a /include directory off your webroot/project directory and call it "functions.php" until such time as you have enough of them to warrant regrouping them.

Welcome to the jungle.

This article does a pretty good job. Don't worry about the message at the top -- the basics of writing functions in php hasn't changed. http://www.brandonsavage.net/how-to-write-a-function-in-php/

PDO is already there, and quite frankly most people prefer PDO anyways as the syntax is more flexible.

Chris, I'm still not clear. A: Are you trying to understand functions in general B: Looking to gain cookbook knowledge of existing php functions?

Hi David, We need more precision from you in describing your question. "It doesn't work" doesn't tell us enough. What specifically have you tried? What sort of debugging have you attempted? How did you determine it isn't working, and have you narrowed down the problem in any way? There are some very important tools for figuring out javascript problems, that are available in the browsers. I tend to use Firefox with firebug because that's what I know the best, but there are similar tools for chrome and IE. What are you using? There is also the well known testbed site http://jsfiddle.net that you can use to test and share your html/javascript coding iterations.

Are you trying to understand functions in general, or looking for more of a cookbook for use of existing php functions?

man5, Do you utilize firebug or the chrome developer tools? They are highly useful for debugging ajax code especially in terms of determining whether or not the calls are actually executing.

Quick update -- recently I became aware that with php5.5 the opcode cache feature of APC is no longer relevant as the zend opcode cache made it into the 5.5 base. If you still want to use the cache feature of APC you need to instead install APCU. I haven't played with this yet, but I assume it's simple enough that api and features are probably still relevant to what I've already discussed in the previous post.

Your "namespacing" isn't anything more than setting up an array key under session. The code in question seems to be concerned with insuring that the actual session file is removed from the server. You aren't ever going to be able to do that with your "session namespace" because it depends on the continued existence of the session file. So -- to Jacques1 point, you should omit all the code that is attempting to mess around with the session lifetime settings (a really bad idea that would actually cause all the server session files to be removed) and just go with simple code that unsets the existing keys.

I'll dog pile and 2nd Kicken's answer. When you look into "caching" what that really means is "memory caching". Memory caching is of course many times faster than either disk or db access in most cases. I want to point out that by default php sessions are stored in small files on the server. File IO is often pretty fast, especially with a system that has plenty of memory given over to disk buffering, but it's often not as fast nor as reliable as memory. And as you already opined, if these are truly shared variables its wasteful to be replicating that data in sessions anyways. Of the memory caching options, there are 2 basic varieties -- "per server" and "shared". If you have a single server, you can setup any of the shared options and run them on the same server, and you essentially have a "per server" setup, but typically the "shared" caches are used in server clusters where one or more "server" caches service 1-n front end servers (Webserver +php) behind a load balancer. The per-server cache that many people already have available is APC. Primarily it's used for opcode caching, but it also can be used explicitly as a data cache. Under *nix servers, APC grabs "shared memory" from the OS, so it's basically dedicated memory that is reserved for use by the system. As it is essentially bound to php (which is often bound to the web server, as in a mod_apache setup) its not sharable across servers. That might be fine, and you can kill 2 birds with one stone by reading all your configuration data and strings through the cache. Once the cache is warmed, this data should come right out of memory as you would like it to. Depending on the size of your code base, you might need to tweak the settings to insure you have enough available memory to keep your dataset in memory. Otherwise, one of the benefits is it's lack of complexity and extreme access speed -- no networking involved or getting in the way. Alternatively, the most used server process caches are Memcache and Redis. Memcache of course was made famous by Facebook who utilized it heavily in their early days. Memcache is basically as simple as APC in most ways, but was designed for large datasets (often used to front relational database result sets). While simple, it has significant gotchas you have to understand, but has many large installations. More overhead than APC, but for name/value caching, it's been the goto product for a lot of the internet's most famous high traffic sites. Redis can be used like Memcache, as a simple "key" (name/value) store, but it has a lot of other features that appeal to certain people. First and foremost, it can be storage backed -- where you can utilize its ability Redis is similar and can be used for simple name/value storage, but it has some tricks that the other caches don't. It has several options for persisting data, which can alleviate the need for "cache warming" on system startup, and programmatically gives you all sorts of features that might be useful for queueing, like pub/sub, "lists" which unlike memcache or APC can be manipulated (the value is not just a black box, but structured data you can sort, push pop and search) amongst other uses. As the saying goes, Redis is very fast as an in-memory cache, but it's not as fast as memcache or APC, and it's more complex and requires a larger footprint. Hope this helps elaborate on the major players I've used in the php application space, and gives you a leg up on your research. From the sound of it, any of the 3 will work for you, so it's just a matter of considering your use case, and doing some testing.

Glad you got things working, and the words of thanks for the members who tirelessly help people out, are much appreciated, and rarely acknowledged.

Your code has some sort of namespacing feature I don't understand. Any efforts you make to remove the session data is going to break that, so I don't really get what that is about. In general, however, php gives you a way of removing session data, and invalidating an id cookie. It is this: // Unset all of the session variables. $_SESSION = array(); // If it's desired to kill the session, also delete the session cookie. // Note: This will destroy the session, and not just the session data! if (ini_get("session.use_cookies")) { $params = session_get_cookie_params(); setcookie(session_name(), '', time() - 42000, $params["path"], $params["domain"], $params["secure"], $params["httponly"] ); } // Finally, destroy the session. session_destroy();

I'm pretty sure it was just "Personal Home Page", but after the Zend guys got involved and it started to take off, they figure that was too lame, and decided to come up with a fantastical story of what it stands for, because the original name is kind of embarrassing now.

Hi Nate, I love to hear that you are already programming at 13. Hopefully you have a project in mind, as the best way to learn the language is to come up with a project and try and build it.

Dale gave you some good advice. MySQL is a relational database engine. The difference between that and a PC database like Foxpro, is that the rdbms is suppossed to be a black box. You talk to it via SQL and you get back result sets. With Foxpro and other PC databases, while many of them support a dialect of SQL, they are basically programs that open the database files. If you have it networked, and 3 people are sharing a db, they are all running the engine on their local machines. With and RDMBS like mysql, it runs on only one machine (the server) even if that server happens to be your workstation. All rdbms's have client libraries that allow you to talk to them, and people have built all sorts of client applications. As dale pointed out, mysql workbench is simply a client application that hides the SQL from you in a lot of cases. I think you already probably know this. There is no magical "use mysql dataset through the internet" feature of mysql. You can connect to mysql using a client program. You can also import data into it in a few different ways. Once you have the server setup on your machine and running in the background (as a service) you can use any mysql client to query it. The simplest of these (mysql command line utility) will let you issue SQL statements and get the results back, and that's the first thing you want to make sure works. It also comes with mysqlimport to let you import files into new tables.

Not only that, but addslashes hasn't been the way to go even when mysql_ wasn't deprecated. You use mysql_real_escape_string(). However --- please DON'T. My advice is to convert your code to use PDO instead.

Hi Izzy. I don't want to sound like a wet blanket, especially since this isn't actually addressing your question, but at this point we really have to insist that EVERYONE needs to convert their mysql_ code to either mysqli_ or PDO/Mysql. The entire mysql_ library is deprecated and will be removed entirely from php in the near future. There is no point in us helping you debug code that is already obsolete when you write it. You should be using either mysqli or PDO, and with bind variables it is a game changer in terms of escaping (you don't need to) and the elimination of SQL injection exploits. Also FWIW, I don't see anyplace where you are doing a SQL INSERT or implementing a form, so I'm not sure what you mean by "nothing added".

Correct. Right now phpfreaks has absolutely no email support. We have been discussing this internally and working on getting email going again, but for now, we're trying to make due without it.

There is nothing I know of. The closest thing I can think of is ffmpeg. There is a pretty decent wrapper library here: https://github.com/PHP-FFMpeg/PHP-FFMpeg/ With that said, it's primarily used by people to transcode and could be used to add effects, although you would undoubtably have to extend it. With that said, it's not editing software.

We have moderation turned on because we're having a lot of issues with spam posts. Once you hit a threshold, your posts pass through moderation.

Packagist is the default directory for packages, that composer reads. It's basically a way of redirecting composer to the location of the actual source. Mostly, people are putting the source for their projects in github, but that is not a requirement for composer to work. Unless over-ridden in the repositories section, composer is going to utilize packagist to figure out where the source for a package is located. However, composer also supports the installation of packages that aren't in packagist and/or github. This is what the repositories section is for -- things that aren't in packagist or are meant to override a default. Composer also builds the autoloader for the php application it is installing, so that the various libraries can be found and autoloaded. You can read more about the concept behind php autoloaders in the namespace era, by googling for PSR-0. As for the composer event hooks like post-install-cmd, take a look at this article: http://www.sitepoint.com/build-automation-with-composer-scripts/

Jacques makes a lot of excellent points, and I don't disagree with him, however, I think a devil's advocate position is merited. First off, there is support for many types ofencryption/decryption with http://php.net/manual/en/book.mcrypt.php Hashing is not encryption of course, and is one of the reasons that people favor it for password access --- because the cipher text can not be decrypted. Your post reflected that you understand this concept adequately. There are times when people want to do what you're asking about, or even more frequently, they are forced to add encryption of certain types of data for legal/compliance reasons. One example would be the storage of credit card information. Jacques points out that if there is a master key and the server is compromised, then the user will obtain the data anyways. That isn't necessarily true. For example, if you have a well secured password, crackers might execute a SQL injection or application level exploit that discloses or leaks data, without fully compromising the system. They will not be able to decrypt the data without the key. I don't look it this as Security Theater, but rather, adding additional barriers to the access of cipher text. One of the reasons this is sometimes implemented, is to deal with the issues inherent in database backups. If your data is encrypted, then a database backup is not a concern, so long as that data is kept independent of the private key. I'm not arguing that you should bother to encrypt the data in your use case, but you should also be free to consider your options, and you should also feel free to implement a proof of concept, even if you ultimately decide not to bother, purely as a way of continuing to explore and familiarize yourself with the tools available and security in general.

You might start with making sure your query is actually valid. $query2 = "SELECT count(*) as jum1 FROM transaksi WHERE nama_kategori = '$namaBidang' AND nama_bayar = 'Uang'";