maxxd

Given your hand-coded error message, I'd venture a guess that neither resource.serviceName nor resource.resourceName are set, and resource::insert() doesn't exist in the $methods array. Also, in the future please use the code tags (< > in the toolbar) when posting code as it does make it easier to read. Yours wasn't bad, but it's a good habit to get in to.

Actually, it's not a bad way at all to think about it (admittedly, it's exactly how I'd set it up so I might be a bit biased). Basically, if you're looking at base functionality, look in the BasicProductPdfWriter class. If it's something specific, look in the specific class. The worst that'll happen is that a developer will start by looking in the specific product class and get referred up the chain to the more general class - you're not so much trying to understand 6 different classes, you're trying to understand 1 class and some very specific differences. The reason to use the interface is not only to ensure a consistent api, but to make the polymorphism transparent. By type hinting the interface in your object methods you can pass the basic writer or any of the specific product classes like so: public function doSomethingCool(IProductPdfWriter $writer){ $writer->add($pdf,$neatStuff); } $writer can then be an instance of ProductAPdfWriter, ProductBPdfWriter, BasicProductPdfWriter, etc. and the method will accept it.

Also looks like you're missing a comma after meter_multiplier on line 5. Any reason why you're selecting meter_multiplier twice (once on line 5, again on 6)?

Make sure you've got error reporting turned on: error_reporting(-1); ini_set('error_display',1); As to the actual cause of your error, it looks like you're trying to go from mysql_* to mysqli_* (which is good) by adding an 'i' to the end of the 'mysql' in the function calls and expecting it to work (which is bad - it won't). Check http://us2.php.net/manual/en/mysqli.query.php for information on how to use query(), and unless I'm mistaken there isn't a mysqli_fetch() function...

Also, check your page source. I could be wrong, but I bet the esc_attr() call is encoding (or possibly just adding a slash to) the quotes around 'checked'. Either way, chances are that'll break it.

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.