kicken

I pretty much gave you the code already. All you need to do is include the jQuery library in your pages and you can learn how to do that by clicking the link I provided. You'd be incorrect. Pure native Javascript solutions to many things are often either messy or long-winded (less so now than years ago, but still...), that's why libraries like jQuery have been created to make common tasks more concise. If you want a native solution, again click the links I gave you and do some reading. Then you have something to learn. We're here to guide, not give you all the answers. I've given you some sample code and links to learn more. Go learn.

I am a aware of that, but I prefer solving things in code since I am not an Apache expert. I pointed that out not because I recommend using it, but so that you're aware of it and can check it. You say you get this error on one sever but not the other. That kind of situation tends to be due to configuration differences, such as one being configured as session.auto_start=On and the other being session.auto_start=Off.

No It doesn't matter how many times your page is loaded. What matters is what happens in your code on each individual request. On each request, your code can only call session_start() once. If you try and call it more than once, then you get your error. If you call session_start in your main page and also put calls to session_start in files that you include into your pages then you'll call it multiple times. First from your main script, then again for each include. The easiest way to accomplish this is to literally only call it once. In other words, if you were to search all the files in your entire project for the phrase session_start(), you should only get one result. So a simple way to accomplish that would be to put your session start code into some separate file, say session_start.php then replace all your existing session_start() calls with require_once 'session_start.php'; (path adjusted as necessary). If your code is correctly structured such that your only calling session_start once, then there should be no need to check the session status prior to calling session_start, though doing so may be beneficial in case the session.auto_start php.ini setting gets enabled.

Using jQuery (recommended): jQuery(function($){ $('#yourUL > li').click(function(){ console.log('LI clicked!'); }); }); <ul id="yourUL"> <li>Hello</li> <li>World</li> </ul> If you don't want to use jQuery then it's more complicated. Use functions like addEventListener and querySelectorAll.

session_start will automatically determine if your starting a new session or resuming one that already exists, but this is not what your error is referring to. The error you're seeing relates to calling session_start multiple times within the same request. The function is only intended to be called once at the start of your request, which is not the same as at the start of every *.php file you have. If you want to have your separate pages that people request and not re-design your application to use a common front-end script or some framework then what you should do is have a common include file that handles your session (and other stuff as needed) and include that in each of your main entry pages using require_once. So your entry points should be coded something like: <?php require_once './includes/common.php'; //whatever else your script does And your common include would just be <?php session_start(); //whatever other common code you want This common include could contain things like your session management code, database connection code, function definitions, etc. Note: there's also a php.ini setting called session.auto_start. If you've enabled that then you don't need to manually call session_start().

If you're talking about the code in your OP causing a copy to be made, then it wouldn't as posted. If you un-comment that line that appends to the array then that would cause a copy to be created. A copy is only generated when your code does something that would cause the array to be different from it's original. Simply passing it around between functions/objects doesn't do this. Side note: $stmt->execute(); doesn't return an array (assuming $stmt instanceof PDOStatement). You'd want $stmt->fetchAll(); to get an array;

Indeed, you should just be filling in both columns regardless of if they are the same or not. It doesn't make sense to do otherwise. You could use COALESCE to use whichever column is not null in your sorting. ORDER BY COALESCE(s2.city, s2.school)

Make your join a LEFT JOIN and add the job id condition as part of the join. SELECT menu_name, menu_price, menu_item_name, menu_item_category, b.menu_item_id, a.menu_id, d.job_id, d.menu_item_qty FROM ssm_menu a INNER JOIN ssm_menu_connection b ON a.menu_id = b.menu_id INNER JOIN ssm_menu_items c ON b.menu_item_id = c.menu_item_id LEFT JOIN ssm_menu_order d ON c.menu_item_id = d.menu_item_id AND d.job_id=27 WHERE a.menu_id = 1 On a side note, consider re-formatting your queries. Your current style is quite difficult to read, something like what I put above is much easier.

I haven't used those particular options, but I'd think you just need to include the full namespace path of your class in the column value. PHP would then use auto-loading if necessary to load the class definition.

One way to help decide if you should bother with DI is to ask whether anyone outside of your code has an real reason to create said object. As an example, I has a project where there was a service to start background jobs. The method startJob() would return a Job object that detailed things about the newly created job and have a couple methods to manage it. There's really no reason for anyone other than that method to try and construct that class so there's not much point in going though DI for it. Instead it just does return new Job($details);

You can't really use any kind of Rewriting to solve the issue as far as I could see. I tried doing a little searching last night before posting for potential solutions but couldn't find anything. Because your friendly URL maps to a valid directory mod_dir is going to want to redirect in order to add that trailing slash unless you disable it with DirectorySlash Off. Personally, I'd go with the DirectoryIndex solution I mentioned above, I think it's the best overall solution if you want to keep your current folder structure. It means your URL will end with a /, but that fine IMO. Just isolate the configuration to your gallery directory by putting it in it's own .htaccess file or in a <Directory> block in your VirtualHost configuration. If that trailing / is really a problem for you, then my second choice solution would be to just move your gallery directories into a sub-folder or something so they don't match your pretty URLs. Rewriting is common, but usually a person's pretty-url's don't match actual filesystem paths. Either the content is in a database and not in a filesystem at all, or it's stored differently in the filesystem (such as with an extension that is added by the rewrite). Usually if a url maps to a valid file/directory people want that file/directory to be served which is why you see a lot of RewriteCond's checking for !-d and !-f. Your problem is due to the specific condition of having your desired pretty URL's match your filesystem which is causing a conflict between what mod_dir wants to do and what mod_rewrite wants to do. There's a handful of cases of this issue I saw searching google, but not very many. Maybe there's a solution that will resolve the conflict while keeping your structure, but I couldn't find it and don't feel much like continuing the search when there are simple alternatives.

One option might be to ignore mod_rewrite and instead use DirectoryIndex. Most people only use this to set an index file name for directories, but you can actually set it to a specific URL which will handle requests for directories. That script can then grab the URL requested and handle it as needed. /client1/gallery/.htaccess DirectoryIndex /client1/gallery/photo-gallery.php photo-gallery.php <?php if (!preg_match('#/client1/gallery/(.*)/$#', $_SERVER['REQUEST_URI'], $matches)){ die('Invalid request'); } else { $gallery = $matches[1]; } ?> <!DOCTYPE html> <body> <p>Browsing <?=$gallery?></p> </body>

This tells me you have an actual directory named 2019-holiday-party inside your gallery folder. When I created a similar directory on my end then I get results similar to yours. The problem is mod_dir which in addition to handling DirectoryIndex files, I'm not sure exactly how it's interacting with your mod_rewrite rules, but it appears as though it's triggers based on the original request url instead of the re-written URL. When it issues the redirect however it still picks up the query-string that was added to the re-written URL. This trailing slash behavior can be disabled by setting DirectorySlash Off in your configuration. That should resolve the problem, though I'm not sure it's a good solution. Another solution would be to make sure your pretty URL's don't map to an actual directory on the server.

That would be ideal, similar to what I did in a previous post. The important bits of the log are from the [rid# bit til the end of the line. There's a lot of info before that which can be removed.

Then I guess you're stuck figuring it out on your own. Without new info there's really nothing else to be said. The rules you've posted work just fine for me on Apache 2.4. Maybe there's an issue with 2.2 causing a difference, but I'm likewise not going to go through the hassle of setting up an Apache 2.2 environment to test. Your re-cap above has various errors in it, but I'm assuming they are just typos trying to transfer data to the post and not actual problems because otherwise Apache wouldn't start and you'd have no output.

You could post the log output. To keep it brief, the best thing to do would be to stop the server, make sure the log file is empty, start the server and run the CURL command to request your page. That way the log file will only contain the details from that single request and be easier to follow.

You'll have to do some troubleshooting then and figure out why. I don't use a Mac, MAMP, or Apache 2.2 (2.4 is current). As far as I can tell looking at the Apache 2.2 docs that configuration should be valid. Check your error log, see if it says why it won't start. Try starting it from a terminal window manually, see if that shows anything. Try a syntax check on the config file.

It would appear MAMP is using an outdated version of Apache. Try this instead. <VirtulHost *:80> DocumentRoot "some path" ServerName local.mydomain LogLevel debug RewriteLog "/Applications/MAMP/logs/rewrite.log" RewriteLogLevel 6 </VirtualHost>

Replace (or comment out) your current LogLevel in the virtual host. <VirtulHost *:80> DocumentRoot "some path" ServerName local.mydomain #LogLevel debug LogLevel rewrite:trace6 </VirtualHost> Whenever you get things working, switch it back to what you had before or your log will get big fast.

Neither of the LogLevel directives you show are what I posted. LogLevel rewrite:trace6 You need to have the correct setting to get any log output. When changing the httpd.conf you need to stop and start the server for the change to take effect.

Appears to work just fine for me if I attempt to re-create what I'm presuming you have on your end. d:\Users\Keith\Documents\PHP Samples>curl -ik https://samples.test/client1/gallery/2019-holiday-party HTTP/1.1 200 OK Date: Wed, 04 Dec 2019 22:55:34 GMT Server: Apache/2.4.26-dev (Win64) OpenSSL/1.1.0e mod_fcgid/2.3.9 X-Powered-By: PHP/7.2.18 Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <body> <p>You are viewing gallery 2019-holiday-party.</p> </body> D:. | .htaccess | \---client1 | menu.php | \---gallery photo-gallery.php Is your photo-gallery.php script possibly issuing a redirect? If you edit your main httpd.conf file instead of a .htaccess file, you can enable rewrite trace logging. LogLevel rewrite:trace6 This will generate step-by-step logs in your server's ErrorLog file showing how your rules are processed. You'd get a bunch of entries that look something like this: [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] strip per-dir prefix: D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party -> client1/gallery/2019-holiday-party [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] applying pattern '.*' to uri 'client1/gallery/2019-holiday-party' [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party' pattern='!-d' => matched [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party' pattern='!-f' => matched [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party.php' pattern='-f' => not-matched [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] strip per-dir prefix: D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party -> client1/gallery/2019-holiday-party [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] applying pattern 'client1/gallery/(.*)$' to uri 'client1/gallery/2019-holiday-party' [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/2019-holiday-party' pattern='!-f' => matched [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] rewrite 'client1/gallery/2019-holiday-party' -> 'client1/gallery/photo-gallery.php?gallery-id=2019-holiday-party' [rid#24d13ce2180/initial] split uri=client1/gallery/photo-gallery.php?gallery-id=2019-holiday-party -> uri=client1/gallery/photo-gallery.php, args=gallery-id=2019-holiday-party [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] add per-dir prefix: client1/gallery/photo-gallery.php -> D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] trying to replace prefix D:/Users/Keith/Documents/PHP Samples/ with / [rid#24d13ce2180/initial] strip matching prefix: D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php -> client1/gallery/photo-gallery.php [rid#24d13ce2180/initial] add subst prefix: client1/gallery/photo-gallery.php -> /client1/gallery/photo-gallery.php [rid#24d13ce2180/initial] [perdir D:/Users/Keith/Documents/PHP Samples/] internal redirect with /client1/gallery/photo-gallery.php [INTERNAL REDIRECT] [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] strip per-dir prefix: D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php -> client1/gallery/photo-gallery.php [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] applying pattern '.*' to uri 'client1/gallery/photo-gallery.php' [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php' pattern='!-d' => matched [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php' pattern='!-f' => not-matched [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] strip per-dir prefix: D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php -> client1/gallery/photo-gallery.php [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] applying pattern 'client1/gallery/(.*)$' to uri 'client1/gallery/photo-gallery.php' [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] RewriteCond: input='D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php' pattern='!-f' => not-matched [rid#24d13ce5bb0/initial/redir#1] [perdir D:/Users/Keith/Documents/PHP Samples/] pass through D:/Users/Keith/Documents/PHP Samples/client1/gallery/photo-gallery.php

Perhaps you should just post your whole re-write configuration. Make sure you don't have extra configuration directives in other areas that might cause the problem (httpd.conf, .htaccess files)

Your mac might have it already installed. Open a terminal window and try running the curl command. The URL that caused the response (url X). Given your original rules that would indeed be the pretty URL. If you create a reverse rewrite to map your ugly URL to your pretty url, then in that instance you'd want to use R=301. You use it when you don't want further re-writes to be processed, which is generally the case. For example, if you had both your pretty URL to ugly URL rewrite (Rule A), and a reverse ugly URL to pretty URL rewrite (Rule B) and didn't include the [L] you'd end up in a loop because Rule A would rewrite the request to the ugly URL. Then Rule B would re-write the ugly URL back to the pretty URL and redirect the browser which would then request the pretty URL again starting the process over (pretty -> ugly -> pretty -> redirect).

It means the server doesn't notify the browser that the URL has been changed. The server just handles the request using the new URL and returns the result and the browser is non the wiser. As a result, the browser just shows the original unchanged URL. It means the server will send a response back to the browser telling it that the URL has changed and it needs to re-request using the new URL. As a result the browser updates it's address bar and re-requests the new URL. Then the most likely explanation is that ?gallery-id=2019-holday-party bit is there from the beginning of the request (ie, you're linking incorrectly). I find when testing rewrites the best thing to do is ignore the browser and instead using something like curl or wget to request the pretty url and see what the response is. curl -i http://example.com/client1/gallery/2019-holiday-party Get yourself a copy of CURL and run the above command and see what it says (post it here if you're unsure what the output means). It does, in a way, by telling the search engine that "The URL you requested (X) has changed to the url (Y) forever, so don't request it again". Your browser can understand that request as well, it's not a search-engine specific request.

They are related because these control what mod_rewrite does after it's re-written the URL. As has been said multiple times, [R] causes mod-rewrite to instruct the client to re-direct to the new URL. [L] causes mod-rewrite to stop processing any further re-write rules. You've been told to remove [R], but keep [L], yet you keep removing both.