kicken

His explanation of regular expressions and the first argument of RewriteRule is pretty poor IMO, but you did miss one part of it at 12:20.

Instead of the LEFT JOIN/NULL check, create a query to pull the order_id of all the rows with codes 13/3. Use that as a sub-query in your main query with a NOT IN condition in the where clause. select * from blah where order_id not in (select order_id from status where ...)

It sounds to me like that might be the case, which is quite an unusual setup. Generally speaking your only supposed to use one or the other, not have both. I don't think there is any way to change which is used other than re-compiling PHP with the correct flags. If you didn't build PHP yourself and instead got it from your OSs package manager you may have the wrong packages installed. var_dump($db->getAttribute(PDO::ATTR_DRIVER_NAME)); var_dump($db->getAttribute(PDO::ATTR_CLIENT_VERSION)); Will tell you what driver/version your using.

I don't think you are using the mysqlnd driver, your using the libmysql instead. If it were the ND driver I'd expect it to say something more like: pdo_mysql PDO Driver for MySQL enabled Client API version mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $ You'll need to look into changing your driver or just work around the string values.

What exactly does it say under the pdo_mysql section of your phpinfo() output?

Just because it's running continuously doesn't make it constrained. Constrained has to do with limited resource availability, like needing to run your script on a small VM with only 1G ram for example. You could always impose your own artificial constraints, such as keeping your scripts capable of running with memory_limit=256MB, but you need to also decide if that's reasonable for the environment/task. In my experience that's usually fine for most web scripts. Being a continuously running script isn't going to affect PHP's ability to clean up memory either. The clean up is something that happens whenever PHP needs to do it. I don't know the finer details of when exactly PHP decides to run a GC cycle, but I tend to assume it does so when leaving a scope or when hitting an OOM condition trying to allocate memory for something. It's generally not relevant when they happen though, bottom line is that they do and the end result is your dead objects won't be hanging around eating up memory. Not entirely sure what you mean by that. You use a singleton when you only want (or need) one instance of a particular object, for example your database connection or session data. There's no requirement that that object some how link back to everything that's using it. TimeUnit to me sounds like it's probably a fairly small/easy to make object so I'd just do new TimeUnit('blah') whenever one was needed, similar to just doing a new DateTimezone('UTC') whenever I need one instead of trying to make one global instance. I reserve this singleton strategy for cases where either I truly want only one instance or the objects are large and complex to make (ie, require several database queries, some heavy processing, etc) and having one shared instance is fine. I tend to call such a variable a $cache but registry probably is fine as well. If you're on PHP 7, you could shorten your code a bit: static $cache=[]; $cache[$class] = $cache[$class] ?? new $class; return $cache[$class];

No it isn't. It's set to 128MB according to your error message. 134217728 bytes = 128MB Make sure you're editing the correct php.ini file, use phpinfo() to find it if necessary.

You have what appear to be a number of problems with your original query. FROM chat_message AS msgs LEFT JOIN chat_to_users AS msgsTo ON msgs.chat_message_id = msgsTo.id AND msgsTo.to_user_id = 7 Here you are joining based on the condition chat_messages.chat_message_id = chat_to_users.id. Both of those columns are AUTO_INCREMENT PRIMARY KEYS according to your table definitions which means that condition makes no sense. Only one side of a condition should be to a AUTO_INCREMENT column, the other side needs to reference a regular INT column that's a reference. Based on your table definitions, you probably want to be making the condition on the chat_to_users.message_id column FROM chat_message AS msgs LEFT JOIN chat_to_users AS msgsTo ON msgs.chat_message_id = msgsTo.message_id AND msgsTo.to_user_id = 7 You also seem to have an order_id column that is linking the tables. Whether this is necessary or not is unclear, but if you're expecting them to be the same then that should also be part of your join condition. FROM chat_message AS msgs LEFT JOIN chat_to_users AS msgsTo ON msgs.chat_message_id = msgsTo.message_id AND msgs.order_id = msgsTo.order_id AND msgsTo.to_user_id = 7

The issue is that either tpl_vars is null or mDelivery is null. Check that when using that template you're defining the cart variable. Check that it's mDelivery property is is an array.

The logic $number != 101 OR $number != 102 is always true. Look at the conditions separately for various cases: Case 1) $number = 99 $number != 101 => true $number != 102 => true true || true => true Case 2) $number = 101 $number != 101 => false $number != 102 => true false || true => true Case 3) $number = 102 $number != 101 => true $number != 102 => false true || false => true What you want is AND, not OR. Case 1) $number = 99 $number != 101 => true $number != 102 => true true && true => true Case 2) $number = 101 $number != 101 => false $number != 102 => true false && true => false Case 3) $number = 102 $number != 101 => true $number != 102 => false true && false => false

I've more or less stopped typing tags in at this point. It's inconvenient to not be able to but what ya gonna do. For longer posts I usually compose them in notepad then when done move them over to the text area and insert all the quotes/code blocks/formatting using the appropriate buttons. More work, but make the post look right. I miss the old text-only editor still.

PHP saying there is a syntax error on line X doesn't necessarily mean that the error is actually on line X. It could in fact be anywhere from line 1 through X. The line PHP reports is just where PHP finally realized there is a problem. With issues such as missing quotation marks or missing closing braces PHP will be able to continue parsing the source for quite a while before realizing something is amiss. Most of the time, the line number reported gets you close, but if nothing appears wrong there you need to start back tracking until you figure it out.

The order you want depends mostly on how you'll be using the index in your queries. I'd venture that in an order system you're most likely going to be joining orders to the details then to the products to generate invoices and such, which would have queries like: select * from orders o inner join order_details od on od.order_id=o.id inner join products p on p.id=od.product_id A query such as that would want your UK defined as (order_id,product_id). With that order the UK can be used to enforce your foreign key relationship on the order_id column and be used to speed up the join between the orders and order_details tables. If on the other hand you were doing a query based on products, such as to find popular products you might do queries like: select * from products p inner join order_details od on od.product_id=p.id For that kind of query you might consider the (product_id,order_id) order so you could use the UK to handle your product_id foreign key and the join to the products table. In either case, assuming both order_id and product_id are foreign keys then your UK can satisfy the index requirement for one of them and the other would need it's own index. Neither order is particularly bad or good in this situation as you need at least two indexes anyway. In such a table design you don't necessarily even need your ID column so you could just make your PRIMARY KEY be (order_id, product_id). Some people prefer always having a auto_increment primary key but in the scenario proposed it's not necessary and could be removed. More indexes mean more index management and disk space usage. That can potentially lead to slower performance when inserting/updating/deleting data, but wouldn't have any significant impact on selects. As such, you should try and limit your indexes to only those that you absolutely need to make your system function well. Until your system grows to a very large scale (millions of rows), it's unlikely you'd notice any problems from extra indexes though. There's no efficiency to be gained from having the separate PK and UK there as far as I am aware. A single multi-column primary key would be just as effective and save an index.

It is in the case you setup in your original post. I know you had some other thread ended up talking about this whole object-oriented sub/super type thing but I didn't really pay attention to it so am unfamiliar with the details. Looking at just this thread in it's own context the answer that your unique constraint is unnecessary is factual. In your original post you show that ID is a primary key (signaled by the (pk) bit). By definition, a primary key is unique across the table which means it's the only thing needed to find any particular row in the table when doing a join or a search. As a result, including it in another unique index is mostly pointless as discussed before. Your link describes a somewhat different situation from what you originally posted. The unique constraint is there because it's necessary for a foreign key in another table, and that foreign key has more to do with enforcing row types than to support joining of tables (as implied in your question "..using that as a join to another table"). In all the tables in that stack exchange example, the veh_id column is the only thing strictly necessary for the DB to handle all the joins and link the tables together. The rest of the columns have to do with your type enforcement. I'm not sure why they used separate primary/unique keys, I think the whole thing could have been done by making a single multi-column primary key which might make the whole thing easier to understand. Because indexes work essentially left-to-right, so if you want to take advantage of a column being part of an index, it either has to be the left-most column of the index, or you also have to specify all the columns prior to it. If you define the order as (id, product_type_code) then you can't use that index to search for a product_type_code unless you also specify an ID (and since ID is unique, that makes the product_type_code mostly useless). However if you define the order as (product_type_code, id) then you can search for a product_type_code using that index and get all the matching ID's as a result. Applying this to your stack exchange example, it also means that you in fact cannot double-dip on your indexes and will need to create extra ones to support your foreign key definitions. Because veh_id is the value that ties all the tables together, you want it to be the first value in your unique / primary key constraint. As a result the veh_type_code will need it's own index to support that foreign key definition.

The foreign key constraint needs a suitable index on the column, but it doesn't need to be an index dedicated to that column. So yes, you can double up your unique index if you create it properly. In order to re-use it, the foreign key column must be the first column in the index, so when you create it you want to do CONSTRAINT UQ_blah UNIQUE (product_type_code, id) and not CONSTRAINT UQ_blah UNIQUE (id, product_type_code). As mentioned though, in the scenario you laid out, the unique constraint is entirely unnecessary as your ID column is already unique by virtue of being the primary key so you'd just make a simple index on the product_type_code column. In a scenario where Id wasn't a primary key and a unique constraint was necessary then you could double-dip like that.

The MySQL manual says: So it would seem you are stuck in that case. I generally use SQL Server these days which does allow the name to be specified and I use PK_<tablename>. I use a similar format for other constraints, just with different prefixes/suffixes. How you name them doesn't really matter though, many people just use auto-generated names and it works just fine.

If column 3 is unique across the entire table, then MySQL only has to search column 3 using it's unique index to find the one matching row on your join. Column 1 and column 2 become essentially redundant and you could just exclude them entirely.

If that column by itself is unique, then any set of columns that includes it will automatically be unique, there's no real need for an extra key.

Don't be afraid of having to re-factor things in the future. You don't have to get the perfect layout from the get go. I find that many times even when I tried to plan for the future and design accordingly I'd usually miss something and end up doing some refactoring anyway. Best to just wait until you know what you need rather than guess at what you think you'll need. The book/component table structure sounds fine. If in the future you decide to split it up further you can. If in the future you decide to do pages/sections you could probably do so with relatively little changes to the tables.

Aka, poor implementation. No JS is necessary to avoid loading the full sized version, you just link it separately. <a href="full-size.png"><img src="thumb.png"></a> I personally wouldn't, no. I have a dual-screen desktop so I'd open the book on one screen and Photoshop on the other. In the particular case of Photoshop it seems unlikely in general anyway to me. The person would need a desktop to run Photoshop on anyway so if they were trying to follow along and learn why not just open it in a browser on the desktop. Right, but if you're loading appropriately sized images then 30 images loading shouldn't really be a big deal. A full-size 1920x1080 scaled down to roughly phone-screen sized images should only be around 20-100k in size. 100k * 30 = ~3MB. 3MB on an average mobile connection would take all of 1 second to download. It's basically illegible sure, but that's where the previous point of having mobile-friendly versions comes in. Alternatively, link the illegible version to a full-sized version they can load and zoom/pan around on demand. A lot of people do things on mobile now, so it's certainly worth considering that market, but in my experience people still acknowledge when something isn't really a good fit for mobile and will move to a desktop/tablet in those scenarios (if possible). I have a friend that does practically everything from her phone mainly because for a long time she had nothing else. From time to time however she will come by to use my computer for things because they are just not mobile-friendly tasks and she recognizes that. Most people I know are still rational about what is and isn't a good fit for mobile, so I think your fear of everyone demanding a refund because your site isn't 100% mobile friendly is irrational. Sure, there may be some because people can be dicks but that's part of business. If your books deal with teaching software and that software is primarily a desktop thing I'd wager most people will interact with the site from a desktop. I'd make some considerations for mobile (responsive layout, smaller images) for those who might want to read some on their phone while away from a desktop (ie, commuting) but wouldn't spend a ton of time up front trying to make that experience perfect. I'd push that until later when everything else is up and running and more time is available to focus on that and/or real customers start requesting it.

If you think the entire screen is necessary to understand the content then so be it and the user's choice of device isn't really your concern. The user can either choose to struggle on their device or move to a more capable device. Your focus needs to be in determining if the entire screen truly is necessary, or if it's just a "nice to have". For a desktop user, it might be nice to see the whole thing, but maybe they only really need to see the top left corner and bottom right corner and you can cut out all the middle stuff. Something I do frequently when creating screenshots it to resize my windows so they are as small as possible to remove wasted empty space then take the screenshot. If you can't per-emptively make the window smaller, cut the middle part later and leave some jagged edges indicating it was cropped.

That's just due to a poor implementation or a slow connection it sounds like. I've had larger galleries load in much less time. If you properly thumbnail your images (ie, not just set the width/height in the html/css) then things should load fairly easily and quickly on any sort of modern connection. Then you link those thumbnails to the full size version so that it will only load if the user clicks on it. In any event, this thread sounds to me like a case of premature optimization. You're worried about performance issues without having any real data showing these is a problem to begin with. 10-12 images and whatever text is pretty much nothing for the modern web for most people on the desktop. On mobile, size can still be an issue, so it can help to reduce the image load. Start by just employing one of the lazy-loading libraries and then see how things work before investing more time into something else more complicated. You're already worried about images being illegible on mobile, so test it and see. If they are then maybe you need to create new images or re-write the text to accommodate mobile which might make the loading problem moot. That depends a lot on how the screenshot is composed. If you're taking a screen shot of a full 1920x1080 monitor to show the pivot table sidebar then yea, it'll be hard to read. If you crop that to just the sidebar and eliminate wasted space to show the specific options however then there shouldn't be an issue. This is something that the <picture> element mentioned by maxxed a few times could help with. Aside from just different resolution images for different devices, you could have entirely different images. Maybe the desktop users get the full 1920x1080 shot because it's similar to what they might see, but mobile users get the cropped version so the pivot table options are legible.

Exceptions are different than errors, and there's a separate function to install a handler for them: set_exception_handler. That kind of handling is only for doing something like logging the error or whatever however, you can't use it to ignore the exception and continue. If you want your script to continue executing despite the exception, then you need to catch it with a try/catch block and handle it appropriately there.

You want the Modulo operator.

I had to change that to posix_kill(posix_getpid(), 11); as the SIGSEGV constant was not recognized. After doing that, and the rest of the stuff mentioned here (ulimit -c unlimited, systemd LimitCORE=infinity, core_pattern change) I was able to successfully get a core dump on ubuntu. root@web1:/tmp# ls -al core* -rw------- 1 root www-data 278056960 May 11 11:24 coredump-php-fpm7.3.19660 root@web1:/tmp# gdb -c ./coredump-php-fpm7.3.3256 /usr/sbin/php-fpm7.3 [...] Core was generated by `php-fpm: pool kicken '. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f0b38a02187 in kill () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007f0b38a02187 in kill () at ../sysdeps/unix/syscall-template.S:78 #1 0x00007f0b2a4ddde3 in ?? () from /usr/lib/php/20180731/posix.so #2 0x000055d5894844eb in ZEND_DO_ICALL_SPEC_RETVAL_UNUSED_HANDLER () at ./Zend/zend_vm_execute.h:649 #3 execute_ex (ex=0xcb8) at ./Zend/zend_vm_execute.h:55503 #4 0x000055d5894886f3 in zend_execute (op_array=op_array@entry=0x7f0b356800e0, return_value=0x0, return_value@entry=0x7f0b19e77b60) at ./Zend/zend_vm_execute.h:60939 #5 0x000055d5893f93a2 in zend_execute_scripts (type=type@entry=8, retval=0x7f0b19e77b60, retval@entry=0x0, file_count=895606832, file_count@entry=3) at ./Zend/zend.c:1568 #6 0x000055d589399380 in php_execute_script (primary_file=0x7ffd8f44a570) at ./main/main.c:2639 #7 0x000055d58925299b in main (argc=<optimized out>, argv=<optimized out>) at ./sapi/fpm/fpm/fpm_main.c:1951 (gdb)