TimeBomb

Is it doable? Of course. Will it have to be more than a simple array function? Probably. Here's some code I roughed together; it could probably use some optimizing. $newArray = array(); foreach($array as $value) { // $value is the nested array $key = $value[1]; // This holds the value #_disabled $disabledInt = intval(preg_replace('(/*_disabled)', '', $key)); // ex. Turns the string 5_disabled to the int 5. $newArray[$disabledInt] = $value; // We'll set the key of the array to the disabled integer. } // Now we can properly sort the array via disabled integer. // Per asort, will be sorted lowest to highest integer. asort($newArray); // This line is optional. // It will slow things down a bit (most array procedural functions are pretty slow), but it will essentially reset the keys to 0 to #, incrementing by one for each array element, as one would normally expect from an array. $newArray = array_values($newArray); The array I used to test with it: $array = array( 0 => array ( 0 => 'test', 1 => '5_disabled', ), 1 => array ( 0 => 'test', 1 => '8_disabled', ), 2 => array ( 0 => 'test', 1 => '2_disabled', ), 3 => array ( 0 => 'test', 1 => '1_disabled', ), 4 => array ( 0 => 'test', 1 => '7_disabled', ), );

Ah, this has to do with what makes a GET request, specifically the symbols used in the URI. First off, when we var_dump $_GET with the aforementioned string, we get: array(2) { ["tmp"]=> string(11) "This Thing " ["That_Thing"]=> string(0) "" } The URI I used was /?tmp=This Thing & That Thing. Or, in other words... /?key1=value&key2. The ampersand is a GET variable seperator. The first GET var is designated by the question mark symbol, but all GET variables following that are separated by the ampersand. The Solution An ampersand intended for visual purposes is escaped in a URL as %26.

I see. I found where the if conditional starts. Can you show me where it ends?

Hmm. I see a possible issue with this line of code: if (isset($_POST['login'])) { Why don't you tell us what code that if conditional is supposed to contain?

The very first validation example for JQuery does just as you described. http://docs.jquery.com/Plugins/Validation

Well, since you insist... 1) Create a function for filtering SQL data instead of copy pasting the code. 2) Or, better yet, use prepared statements with mysqli or PDO. See: mysqli prepared statements and PDO prepared statements. This will help further secure user input being sent to the database. Also, the PHP mysql library is not recommended for production use anymore. 3) Use the password() function in MySQL to further hash the password. You probably also want to salt the password as well. 4) Use sessions instead of cookies for storing the user's data. Though, for a 'remember me' function, you will need to use a cookie. Just make sure the data is heavily secured before it goes into the cookie.

Simplicity is king. It looks nice and works without issue. Nicely done. My only suggestions would be an optional preview option for users and perhaps custom aliases. These are a couple major reasons why I prefer tinyurl.com over most of the competition. /2cents

A 'database driven page' could be/mean a lot of things. I assume that information is being outputted from the database to the user (based on information found in the URL, i.e. via $_GET). You will need to modify the code somewhere along the line. Perhaps either where the data(ex. HTML) is outputted to the user, or where the database checks if information exists. You will want to check for 'bad' information, ex. empty information or an error, and tell it to either redirect to or load(i.e. through include) the error page instead of showing a blank/wrong page. For a more detailed answer, we will need more information.

In this scenario, I highly suggest you use single quotes around strings instead of double quotes. Then you don't have to escape the double quotes. Why is the function htmlentities in quotes? You do not want to treat it as a string.

I came up with the following: function organizeFileArray($array) { $organizedArr = array(); $tmpFunc = function($value, $key, $element) use (&$organizedArr) { if (! isset($organizedArr[$key])) { $organizedArr[$key] = array(); } $organizedArr[$key][$element] = $value; }; foreach (array_keys($array) as $key) { $element = $array[$key]; array_walk($element, $tmpFunc, $key); } return $organizedArr; } It'll produce the same result as your function, but is a lot more dynamic. The downfall is that, after a bit of benchmarking, your function is around 400% faster than mine. So there is indeed room for optimization. I hope it helps, gl. Edit: I just noticed that the function array_walk is completely unnecessary in this scenario. I modified the function to reflect this: function organizeFileArray($array) { $organizedArr = array(); foreach (array_keys($array) as $key) { $element = $array[$key]; $currElement = $key; foreach($element as $key => $value) { if (! isset($organizedArr[$key])) { $organizedArr[$key] = array(); } $organizedArr[$key][$currElement] = $value; } } return $organizedArr; } Your function is only 80% faster than this - much less appalling than 400% faster.

I disagree with the underlined statement. The singleton pattern is an antipattern for a reason. They are unnecessary unless your application is designed poorly. If you effectively use dependency injection, you will never need to use singletons.

While static classes are gray area in some scenarios, and just plain poor design in others, singletons are very much so antipatterns. I would suggest making it a normal object, and using dependency injection.

You could use PHP's array_walk_recursive. $array = array() // sql data in here $types = array('advertisement' => 0, 'friend' => 0, 'other' => 0); function processArray($value, $key) { if ($value == 'bla') { $types['advertisement']++; } elseif ($value == 'blabla') { $types['friend']++; } else { $types['other']++; } } array_walk_recursive($array, 'processArray');

But in PHP, procedural functions are used on a regular basis, even in OO applications. Some functions do not have OO alternatives, and thus must be used procedurally. This is because of PHP's history prior to PHP 5, wherein it was not at all object oriented. A lot of it's base still is procedural. Yes, I know. What I'm saying is that user defined functionality should attempt to fit one paradigm or the other. Making your own classes and function libraries to use in the same project is, IMO, not a good way to go. At the very least, to me, it's confusing. And, indeed, this is why static classes exist. They scratch that "I need a bit of generalized utility functionality without an object" itch while still being OO. It's not ideal, but it fills in an edge case like this better than a group of functions. While I will agree that creating a function library that is not directly related to your OO application is not the best practice, I am concerned that forcing simple, non-OO functions into static classes for the purpose of attempting to keep your application completely OO is poorer practice than simply including the functions. While using both procedural code and OO code in an application is somewhat poor design (although arguably less poor in PHP, due to a majority of its 'base' being procedural), and should be avoided at all costs... forcing non-OO code into an OO application is arguably illogical design. It's like forcing a cube into a circular hole.

But in PHP, procedural functions are used on a regular basis, even in OO applications. Some functions do not have OO alternatives, and thus must be used procedurally. This is because of PHP's history prior to PHP 5, wherein it was not at all object oriented. A lot of it's base still is procedural.

A file can have as many extensions as you want it to have. In this case, .inc indicates that it's a file ment to be included, not run directly. .php indicates it is a file containing PHP code. Having the .php also makes it so the server will execute it so if someone tried to load it directly in their browser they would just get a blank page, and not your source code (like they would with just .inc). That bug where they rename the files is just due to their own coding conventions where they decided to standardize on using a .inc extension but a few files were still named .inc.php Ah, sorry for the confusion. I was thinking you were confusing the extension with an extension I have previously heard of - I thought it was .inc. I heard that it was parsed as PHP, but input was secured. People created unsecured code, ex. code that was SQL injectable, and then set the extension as that, and the code was supposedly fine. I never knew a lot about it, and doing a few minutes of research actually doesn't bring up anything. I fear I may be confusing two or three things with each other.

Hmm, I think I remember reading an antipattern similar to this. Wherein multiple (unrelated) classes unnecessarily extend a base class. I may be wrong, though. I may also be misinterpreting your suggestion. Nonetheless, thank you for your contribution. It's all appreciated. It doesn't necessarily have to be extended, but it's a good way to go if you're using some sort of dependency injection. Hmm, but isn't dependency injection used for injecting objects, not functions, or an object who's sole purpose is to hold methods?

scootstah, thanks a lot for your opinion. This option was definitely in the back of my mind, but I was/am still curious if there would be a better way to implement this. It's looking unlikely. Hmm, I think I remember reading an antipattern similar to this. Wherein multiple (unrelated) classes unnecessarily extend a base class. I may be wrong, though. I may also be misinterpreting your suggestion. Nonetheless, thank you for your contribution. It's all appreciated. Umm, isn't functions.inc.php an invalid use of the .inc extension? Isn't it .inc or .php? I may be wrong, but from the bit that I've read, .inc.php is invalid. ex. https://bugzilla.wikimedia.org/show_bug.cgi?id=18698 But the overall idea is not at all bad. This may be the route [or similar to] that I choose. Thanks.

Yes, this is a concern of mine as well. To stray away from coupling issues, I could make certain that the functions would only need to be used by one object, and then I could place the functions directly into the object. The design problem would then be both the lack of cohesiveness, and the blatant breaking of the "single responsibility" rule. To perhaps make my issue more clear, here are a couple functions I have created that make managing cookies more efficient: public static function setCookie($name, $value, $expire = false) { if (! $expire) { // $expire isn't set, so default to default session time. $expire = static::defaultSessionTime(); // Returns time() + 3600 } if (is_array($value)) { // Allow an array to be easily stored in a cookie. Will be decrypted back to a PHP array upon using the getCookie method. $value = json_encode($value); } $_COOKIE[$name] = $value; setcookie($name, $value, $expire, '/', Core_Config::get('site_url'), false, false); } public static function getCookie($name) { if (isset($_COOKIE[$name])) { $array = json_decode($_COOKIE[$name], true); if ($array === null) { // If the cookie is NOT a json_encoded string, i.e. an array return $_COOKIE[$name]; } else { // Decode the json encoded array back to a PHP array return $array; } } else { trigger_error('Cookie: ' . $name . ' not found.', E_USER_WARNING); return false; } } Note: Core_Config contains default settings. I still have a few places wherein default configurations are hard-coded in. I'll be modifying these occurrences to take advantage of dependency injection, which I've already done throughout the majority of my application. I will also be working on modifying Core_Config to reduce coupling between the application and it even moreso, but that is another project. This doesn't relate to my issue at hand, though. Thanks again.

I have a design conundrum here. I have an application built around a MVC framework, and thus takes advantage of OOPHP. I need to implement functionality into the app wherein this functionality does not affect any object(s). I have numerous custom-built functions that making handling both cookies and caching easier. A few functions are made for handling cookies, and a few for caching. Just to clarify, these functions are completely separate - the only similarity being I would like to know where to place them in this application. They are obviously in no way cohesive with any object - even if only one object ever uses these functions. At it's core, PHP uses many, many procedural functions - because, until PHP 5, PHP never dipped its foot into OOP. We use a lot of these procedural functions in OOPHP application today. I want to add more functions of this nature to an OOPHP application. Up to this point, I have made sure that all static classes, antipatterns (ex. singularities), helper classes, and what-not are not smelling up my application nor framework. Currently, the only issues I am having of this nature are my extended caching and cookies storing/retrieving functions. I am looking to get possible solutions, ideas, or alternatives that could help me solve this design 'issue' in the least smelly manner possible. Perhaps simply using a static class may be the best option here. But I'm quite interested in hearing others' opinions. Thank you.

Oh my... abnormal whitespace. I despise it. There are a lot of characters that it could be. The trim function does not remove everything. The comments in the trim PHP manual entry do have lots of different options as to removing annoying whitespace. I do suggest that you read them carefully and try some of the suggestions.

Well, jesirose's code retrieves all 600,000 rows of data from the table, then spits out all of the rows in chunks of 40. I'm a little surprised this only took 6 seconds, although I assume it's because of the memory limit he put in. Anyways, with a table this big, you should be taking advantage of caching as much as possible, for both MySQL and PHP. To retrieve 40 rows of data from anywhere in the table, use the following query: SELECT DISTINCT website_page_name FROM website_page_names ORDER BY website_page_name ASC LIMIT 40 OFFSET {row start} Replace {row start} with the row number to start at. So if the offset is 100 and limit is 40, it will retrieve only rows 100-140. I must still warn you that while offset will help a lot in this scenario, it isn't perfect. When you use offset, it still iterates through all the previous rows, starting at 0; it just doesn't pay any attention to them when showing the result. Therefore, an offset of 500,000 will still be quite slow. I found an informative article about this issue which you may be interested in reading: http://www.4pmp.com/2010/02/scalable-mysql-avoid-offset-for-large-tables/ You may want to look at the design of your entire database if you really want to completely solve this issue.

Yes I am sorry. That was a typo. It had to be menu indeed. As I typed a few posts back, I would like to have a menu system like this: <ul> <li><a href="/index.php?id=1">Home</a></li> <!-- Is an actual link --> <li>About</li> <!-- Is an placeholder for the submenu --> <ul> <li><a href="/index.php?id=2">Who are</a></li> <!-- Submenu link --> <li><a href="/index.php?id=12">History</a></li> <!-- Submenu link --> </ul> <li><a href="/index.php?id=56">Rental</a></li> <!-- Is an actual link --> </ul> As ifMenu is 1 then its a URL and if its a 0 its a placeholder like About and there is a submenu below it. Because I have a lot of pages and I wanted to create them within a database table so I can edit them later on easy within a administration area, witch I am building later on when I am finished with this menu issue that is driving me nuts right now. If menu items need to link to pages, then you should add a separate column to the menus table: pageId. Wherein the menu table's pageId links up with the page table's id. If pageId is null, then the menu item is a placeholder and not a link. This will remove the need for the isMenu field. Storing pages (which contain front-end content) in the database is poor design, but that's a different subject.

That was a typo in the first table code, I imagine? Supposed to be CREATE TABLE 'menu', not CREATE TABLE 'pages'. Anyways, the menu table needs to have an id and parentId, not just a parentId. And why is there an isMenu field? What's that for? Also, what is the pages table for? What do you define as a page in your application, and why does it need to be stored in the database, rather than some sort of 'view' PHP/HTML file.

I've seen scenarios where the string: "{imap.gmail.com:993/imap/ssl/novalidate-cert/norsh}Inbox" doesn't work, but: "{imap.gmail.com:993/imap/ssl/novalidate-cert}INBOX" works. Perhaps this may be your issue?