requinix

Unfortunately my crystal ball has exploded so I can't use my supernatural powers to instantly know everything there is to know about your application and code. So we'll have to do this the hard way by having you use your fingers and keyboard to type out the kind of information that is important for someone like me to have if I'm to tell you where the problem is. The "File upload failed" message means your INSERT query failed. Why did it fail? To find that out, try using PDO::errorInfo.

You cannot use anything in $_FILES until after you've tested to make sure there's something there to use. In other words, you can only set and use $fileName inside that main if block.

Browse around your site and make sure the browser always says the page is encrypted, or at least it never says it isn't encrypted. With Chrome, for example, a padlock icon on the left of the address bar means it's HTTPS.

Make sure every page on your website is being served over HTTPS. Also check your session cookie settings.

1. Open a new tab or window with a new pen 2. Copy the HTML 3. Copy the CSS 4. Copy the JS 5. Save

Don't layer the background behind the foreground. Layer the foreground on top of the background. Take a DIV of whatever size you want and position it on the page wherever you want the container of all this to be. position: relative but that's basically it. Then add your background images to it. position: absolute and left/top and/or right/bottom however you need. Do a bit of math on the backend to figure it out (or hardcode it, as the case may be). Then add the foreground image. position: absolute so it appears where you want. You shouldn't have to z-index it or anything else. Example It's a bit more hands-on with the positioning than I would like; some fancy CSS might be able to fix that.

Are the images supposed to go "behind" the main table/form/image, or do they flow around it? Can you put this in a jsfiddle or similar?

About z-index, if you want images to the right overlapping images to the left (ie, in document order) then you don't have to worry about z-indexes. Still not sure what the problem is. Making them overlap is one thing, but beyond that it just sounds like you're talking about having multiple images inline with each other. And that doesn't require doing anything more than having multiple images without using line breaks or wrapping. As in <div> <img ...> <img ...> <img ...> <img ...> </div> What you might not be mentioning is that you want certain images on each line. Or a certain quantity of images. In other words, something that depends on knowing the width of the screen...

Well... the most obvious answer to "I want a bunch of images on the same line and then repeated for multiple lines" would be to put the images (as inline or inline-block) inside a block DIV for each line. How about a more thorough description of what you're trying to do? Possibly with screenshots or some rudimentary diagrams?

What's /hosted/redirect? What's trying to POST to it?

I can't tell what your other account is. What's the username or email? You can post it or PM me. I'm being stupid. It should be obvious what the original account is. I do see the account being locked from too many unsuccessful login attempts from 37.147.174.213, but that lock has since expired (while the site was offline). You should be good to go now. I can't really speak to the support ticket thing... Nibble Netwrx owns PHP Freaks so that's why you got that email from them.

You'll probably have to make some other minor changes so that this script can run from a cronjob, but Essentially the change you need to make is to take all of that code, which works for a single page of data, and stick it inside of a loop that goes through all of the pages. Starts at page 1 (or perhaps 0), runs the code that you have now but edited to use that page number, then the loop moves to the next page and starts again until eventually there are no more pages.

Look at the examples and maybe try some Google searches for using PHP to download multiple files with a ZIP archive. There's a lot of information out there and it isn't too hard to find samples you can reference.

That normal technique you have in the code, with the headers, only works for a single file. It cannot be used for multiple files. You've kinda discovered that. Use ZipArchive with a temporary .zip file on the server. Add your files to it, send it, then delete it. One other thing: in your code before you start that work, turn off user aborts.

Not very easily, at least. The opacity changes are asynchronous, which means the code making the changes isn't connected to the code that started the process. The best lead I can offer you right now is that the fade in effect seems to be applied only to the green banner, as far as I can see. So look at that and find out what makes it different from other images.

On the <img> for the green banner, it has set loading=lazy. I randomly checked a few other images that didn't seem to be fading in and they don't use lazy loading. When I load the page, I can see that the CSS opacity on the image is being changed (by Javascript). I can intercept the Javascript that is doing that and see it happening, however it's not an easy matter to see what code is responsible for it. Those preloading things are separate and not related.

I don't know your website. All I can do is point you in a direction to look for more answers. Do you have any sort of lazy image loading set up? Looks like you have some WP theme going - could that be responsible? And it doesn't seem to be "all" images. Mostly just that green wavy banner thing.

Kinda hard to troubleshoot given its nature, but the fade in is being controlled by Javascript and not CSS, and I believe it's code related to image loading. I see a loading=lazy attribute?

Link would be nice.

Well... according to the code, it does use $url twice. Is it duplicated because it's duplicated?

In the days before mobile was big, making a site mobile-friendly was often a matter of taking an existing site and disabling some of the nuisance CSS rules - centered margins, fancy effects, etc. That technique may not produce professional-level results by today's standards, but it can still be quite effective in a pinch.

Oh, weekly? That's quite a while to be out of date, though: that's potentially seven whole days for something to be inaccurate. You can probably update daily. Yeah, go ahead and switch to a cronjob script. That single script will go through all of the pages, beginning to end, grabbing the data it needs. After every page, slow down by sleep()ing for at 1 second - that being a number more than the 60/100 = 0.6 seconds per request bottleneck that you have to stay above. Then have the script run daily. Like, midnight. Or some other non-peak time.

There are different approaches for this sort of problem, ranging from on-demand cached API calls to background cronjobs. How important is it that your data is up to date? Ideally everything would be updated immediately, naturally, but since you can't do that, how old can your data be before it becomes unacceptably old?

No. That <meta> tells a browser to request the page. cronjobs don't use browsers. This doesn't smell right. Why are you hitting the API so often? Why does it have to "loop through again" when it reaches the end?

More or less. When in doubt, check the documentation, and in the case of WordPress, any related hooks documentation. Note that wp_enqueue_script does not say anything about a script ID.