maxxd

The code does look like it should be working - do you have error reporting turned on, and if so, is it displaying an error? And to reinforce Ch0cu3r's point, move away from the mysql_ functions.

Hey all. I'm fairly new to WordPress (not php) and am running into an issue. I need to add link descriptions to 1 of 5 menus on my page. I've read about extending Walker_Nav_Menu() and am attempting that, and it's kinda going well except for one slightly annoying issue - it's returning the wrong menu. I'm attempting to isolate the action to a menu with the slug 'subbrand-menu'. All the code follows: mytheme/functions.php require_once('classes/FunctionClass.php'); $fn = new MyDev\FunctionClass(); add_filter('wp_get_nav_menu_items',array($fn,'buildSubbrandMenu'),10,2); mytheme/classes/FunctionClass.php namespace MyDev; class FunctionClass{ private $_walker; public function buildSubbrandMenu($menu, $args){ if(\is_admin() || $args->slug !== 'subbrand-menu'){ return $menu; } if(empty($this->_walker)){ require_once('MyWalker.php'); $this->_walker = new MyWalker; } \wp_nav_menu(array( 'menu' => 'subbrand_menu', 'container' => 'div', 'container_class' => 'menu-subbrand-menu-container', 'container_id' => '', 'menu_class' => 'menu', 'menu_id' => 'menu-subbrand-menu', 'echo' => true, 'walker' => $this->_walker )); } } mytheme/classes/MyWalker.php namespace MyDev; class MyWalker extends \Walker_Nav_Menu{ public function end_el(&$output, $item, $depth=0, $args=array()) { $output .= "<span class='thisisadescr'>Testing, testing</span></li>"; } } Now, the above actually works quite well except that it's outputting the contents of a menu with the slug 'floater'. Anybody have any ideas what I'm missing here? I'm sure it's something simple but it's driving me crazy right now. Thanks in advance for any and all thoughts, hints, tips, and ideas.

The problem is it's URL-encoding your opening and closing php tags. Where are you entering the code?

Open your developer console in the browser and check the headers and return values. There are a lot of possibilities for why the counter script isn't firing - it'll be easier to debug once you know how far the script is executing.

OK - that's what I thought. Unfortunately, doing that would require changes to the link target pages, which we're not doing. Thanks for the input, kicken and Jacques1!

Sorry, you lost me on the second sentence. Any chance you could elaborate a bit?

OK - there are still some major issues in the code. First off, your config file defines $tbl_name, and your queries use $tbl_names for inserting and selecting (which alone should be stopping everything from working), you've still got the same enormous security holes in the scripts posted, there's no error checking of any sort in place, and relying on using LIMIT in your SELECT query to find the exact record your user inserted is a logical flaw that happens to look like it's working correctly. First off, you really need to use either MySQLi or PDO and prepared statements. Then, you need to check to make sure the insert successfully happened before you redirect the user. Once you determine the insert happened correctly, get the insert_id for the record you just inserted. You can then put that id in session or append it to the redirect URL. Once the user has been redirected to the target page, instead of selecting the top 1 ow attributed to the currently logged in user, use the insert_id you got from the actual row inserted and either stored in session or appended to the URL string, and use that in your WHERE clause (preferable in addition to the $_SESSION stored user_id) in your MySQLi or PDO prepared SELECT statement. Once you've made sure the SELECT statement completed successfully, you can use the data in the results array (or object) to display the data either directly to the target page HTML, or in a form on the target page.

Not sure at all if this is the right place for this post, but it seemed the most applicable spot. Mods, please move this thread if it is more appropriate elsewhere. OK - We've got a client that's using - as far as I can tell - exclusively IE11 and has been running into an issue where IE is apparently deleting the contents of the 'Compatibility View Settings' when the browser is closed and/or the browsing history is cleared. According to the research I've done, this was a design decision by Microsoft when they updated IE to only display the 'broken page' icon when the browser thinks the page is broken (regardless IE's actual ability to correctly parse the page) and is fairly well documented in several different places on the Interwebs. So, I know the issue, and I know that adding an "X-UA-Compatible" meta-tag in the target page's HTML should take care of the problem. The issue I'm having is this - we're redoing the site. Unfortunately, we're not redoing the pages that are causing the current problem, and the client has talked with someone who made mention of (rough quote here) 'a small bit of code that could be added to the link' that would force IE to render in compatibility mode. I'm assuming the client's source is talking about the meta-tag in the link target page, and I haven't found anything in my Google searches to discount that theory, but I thought I'd ask here before I spoke with them about it in case I'm wrong. Is there a flag that I can simply append to the URL that IE will parse and force a specific release-compatible view? Or really any way to force IE to render a webpage to a certain version that doesn't entail messing up the display to every other browser ever made or modifying the rendered page's source HTML?

On top of what mac_guyver pointed out, in post #6 you build the $products array then attempt to print $price['SMX800E']. $price is a string, $products is an array. If I'm not mistaken, php will attempt to return the character at the specified index of the string if you attempt to use the string like an array. I'm not absolutely certain if this last point is true - it may just throw an error. And, admittedly, I'm not going to be chuffed to find out because it's just wrong, so I'd recommend checking your variables and avoiding the issue entirely.

Couple things right off the bat: first, if those are your actual database credentials, remove them from the post. Second, please use the code tags (the < > button on the post editor) when you post code - it makes it much easier to read. Third, the mysql_* functions have been deprecated for about a decade now and will be flat-out removed at some point in the near-ish future - use PDO (preferably) or mysqli_* instead. They both are still supported and let you use prepared statements, which will circumvent the massive security holes you've got in your current script. Google 'SQL Injection attacks' for more information. I'm assuming the spaces between the dollar sign and the variable name is a typo, as I don't think php will properly parse that, although it may not be noticeable if you're developing with errors turned off as you're assigning all the $_POST values to local variables and then ignoring those variables completely. Now, on to the meat of the question. If you've got the data saving (dangerously) to your database, you're halfway there, technically. On the account-tr.php page, you'll need to write a SELECT sql statement that pulls the newly inserted data from the database. So, on the initial page, after the insert completes successfully, you'll need to get the insert_id() and either store that in $_SESSION or pass it via the URL string (?id=xxxx). I'd recommend using sessions in this case, personally. Use that to select the row you just inserted, and you can print out the data on account-tr.php. Also, you're connecting to and selecting the same database twice - once in config.php, once in your processing script.

Give this a shot and see if it gets you the information you're looking for. You may have to start with t_persons as your base table (as you have, I switched it to t_incidents because that seems to be the main data table but the join directions may cause some weirdness...) $qry = "SELECT p.PersonID ,p.FamilyName ,p.FirstName ,p.OtherNames ,p.Gender ,p.ImagePath ,i.IncidentID ,i.Incident ,i.IncidentDate ,s.StatusID ,ok.KeywordID ,c.Country ,a.Agency FROM t_incidents i LEFT JOIN t_persons p ON i.PersonID = p.PersonID LEFT JOIN t_countries c ON i.CountryID = c.CountryID LEFT JOIN t_status s ON i.StatusID = s.StatusID LEFT JOIN t_offenceskeyword ok ON i.OffenseKeywordID = ok.KeywordID LEFT JOIN t_Agencies a ON i.AgencyID = a.AgencyID WHERE p.PersonID = :pid"; Basically, you don't need all the ID columns unless you plan on specifically doing something with them (sorting, filtering, etc.), and even if that is the case, you don't need to select them both. You're joining on the column value, so the values will be the same. Of course, as Barand pointed out, you're going to want to bind the $PersonID to the :pid parameter before you can actually run the query.

http://php.net/ChangeLog-5.php#5.6.0 Also this: http://us1.php.net/migration56

Look into Apache rewrite rules. You can do it with mod_rewrite or an .htaccess file, which is probably easier, especially if you're using shared hosting where you don't have access to the Apache config file.

To tell you the truth, if you're making the switch, I'd recommend PDO() over mysqli(). Despite the similarities in name, I've found it much easier to refactor old-school mysql_* code to PDO than mysqli(). And PDO is a bit more forward-looking as it's not specifically tied to one database type.

Nope - I haven't used those functions in years. I'm actually trying to impress upon someone that some code needs to be updated and was hoping to light a bit of a fire. Thanks for the info!

Hey all. Obviously, the mysql_* functions are deprecated and have been for quite some time now, and will be removed soon. As of 5.5, using them should result in an E_DEPRECATED error, so it looks like we're getting closer to that happening. My question is - has anybody read or heard a reliable statement as to which future version will officially remove even legacy support for the functions? Like 5.x, 7.0, etc? A Google search isn't returning anything official so far as I can see, and I was curious.

Jacques1 - great info - thanks!

I am so afraid that's the culprit. The server is run by the client, and unless they specifically turned on magic quotes, I'm a little concerned that php may have not been updated in however long. At which point I can just revert all the changes and let everything run on mysql_*, but still...

Yeah, I found out about quote() wrapping the string already and took care of that. And honestly, I didn't think I should see the escaping in the database - I'm wondering exactly what was done in the past that resulted in the issue to begin with. When doing my own code, I always used htmlentities() or htmlspecialchars(), so I was a bit confused. Thanks for the info! I completely agree and I look forward to getting in there to do exactly that. Thanks for the info and advice, everybody - I'm going to mark this thread complete but feel free to keep the discussion going...

I agree it would be better to do all at once, unfortunately that decision isn't up to me. Hopefully we'll get to it soon, but right now not so much. We've got in-line queries scattered all throughout the site that are already using the existing sanitization method. Obviously I don't want to just allow the user to insert unsanitized data directly into the queries, and I was hoping we could get by usig quote() until we can convince the client to let us redo the site entirely. At that point, it's prepared statements and not a worry for the future... I do use PDO and prepared statements, but this was a legacy piece that was inherited. The transition actually came about because I was tasked to handle some very minor maintenance on another part of the site and noticed the msql_* functions in the abstraction class. Brought it to the attention of the higher-ups and they were kind enough to listen and let me run with it despite the crazy backlog of work we're looking at.

Hey y'all. Hopefully quick question on something I've not come across before. I am doing a quick and dirty update on an existing site that is using the mysql_* functions to use PDO, and I'm wondering how much of a corollary there is between the mysq_real_escape_string() function and PDO::quote() method. We had a sanitization method that returned the submitted string after running mysql_real_escape_string() on it, and I've updated it to return the string after passing it through quote(). What I'm noticing in phpMyAdmin, though, is that new records inserted using the quote() sanitize don't encode quotes or add slashes or evidence any of the things that apparently mysql_real_escape_string() used to do (I always used a different scrub method in the past so I'm really not familiar with how it works under the hood). Is using quote() going to offer an equivalent level of protection against injection? Hopefully I'll get the go-ahead to take the time and revamp all the queries to use prepared statements, but right now that's not in the cards. At least the old site did abstract database interaction so I'm not chasing mysql_* functions all over the site... Any opinions and thoughts are very much welcome and thanks in advance!

ignace is right - if class second extends class first, it's already got access to any public and protected methods and properties of the first class. So in your code, you would instantiate the second class, then call methods from either the first or second class. The only things you wouldn't have access to are private properties or methods, as you would expect. Inheritance is useful and easy to use, but also pretty heavily coupled. If you're trying to learn OOP in php, I'd recommend the book PHP Objects, Patterns, and Practice by Matt Zandstra. Personally, I found it an informative and fun read. Of course, I'm kind of a nerd, so fun is subjective, but hey.

You're also going to want to edit your post to remove the database credentials. Won't help your problem (listening to Barand will do that), but it will certainly increase your db security.

If you're going to load all the options at page load, you can output a select with <optgroup> tags. If you want to dynamically fill the drop-downs as your user makes selections (for instance, select 'Ontario' from the 'province' drop-down, then the separate 'cities' drop-down populates with the cities in Ontario - I've always called it cascading selection, but not sure if a Google search on that will result in anything as I may be the only person to refer to this setup that way...) you'll want to look at AJAX. Which may actually be easier as you don't have to store each individual selection between page loads because the page is only going to load once. So you just need to read the values of the form once the user fills out and submits the entire form.

Hunh - it is valid. Never seen it in the wild, myself, but thanks for the info!