requinix

POSTed forms a very capable of including GET parameters: all you have to do is put them in the form action's URL. The problem here is that the form action's URL does not include any GET parameters.

Submit the form and look at the URL. Do you see an "id" in there? If you want the form to submit back to the same page then remove the form's action entirely. Because the default for a form without one is to submit back to the same page. And stop using PHP_SELF.

Spend some time learning about PHP so that you can understand what sort of changes you will be making. // this variable is defined outside of foo() $outside = 123; function foo() { // you cannot use $outside here echo $outside; // warning: undefined variable } foo(); // if you want to use a variable inside a function then you must pass it as a function argument function bar($inside) { // you can use $inside here and it will have the same value as $outside echo $inside; // 123 } bar($outside);

function dodaj($nazwa){ $link->query('INSERT INTO zakupy VALUES(null,\''.mysqli_real_escape_string($nazwa,$link).'\',\'N\');'); Variables like $link defined outside of functions are not available inside of functions. Pass $link as an argument to the function, like you're already doing with $nazwa.

Fix your queries so that you don't try to include columns in the SELECT if you aren't GROUPing BY them. SELECT a, b FROM foo GROUP BY a /* bad because "b" is not being grouped by */ How you fix a query depends on what it needs to do...

Sure: make sure the value stored is a time in the future instead of the current time, then modify the things that query the table for what to show so that they ignore things in the future. Exactly how you do that is going to depend a lot on how the blog is written...

I use mostly PHP Debug and PHP Intelephense.

If "the recommended script" is conflicting with "the dataLayer" then my first step would be to troubleshoot why.

That would be a PHP source code file and line number, but the error happened on APCUIterator::current which is internal code so there is no file or line number. But errors do need to report some location, thus that.

Don't hijack threads. What code have you tried so far, what has it done, and what did you expect it to do?

There's no "tapping into" or "breaking into" here. If the code running on both subdomains can access the same source of session data (probably files) then they can share the same sessions. This sort of setup happens all the time. If the sessions are files then it's easier to have the sites on the same server - naturally. If the sites weren't, or were "in the cloud" or otherwise distributed, then a database would be better/easier.

Have you checked php-fpm's own error logs?

APCUIterator is part of the apcu PECL extension. According to the changelog, you need to have version 5.1.21+ for PHP 8.1 support.

If you're sure that the user can browse the other site perfectly fine, with the same session information as the first site, then the problem will be somewhere in the code that gets the member ID and stores it in the database...

What you originally described doesn't seem to match up with what you've posted. I can't tell what is supposed to be what. Can you throw an example into a fiddle? To the question, fixed positioning is the basic answer. Sticky could work too. They both require some setup but either one should do what you want.

You talk about a member ID not being "registered" and post some code that deals with session cookies. I have no idea if the two things are supposed to be related. When the page on the second subdomain handles the form data, either it can access the session data or it cannot. If it can't then you have cookie and/or session data problems, and if it can then you have some problem getting the ID into the database (I guess?). It's hard to tell without knowing your application(s) and having a more detailed explanation of what you're seeing and what you expected to see.

I think the main problem here is that you have a HTML and CSS question and haven't posted any of your HTML or CSS.

There are more efficient methods than creating a massive regular expression. For instance, 1. Have the text file be sorted by domain 2. Get the domain from each email address 3. Do a binary search inside the file for the domain

It is all PHP code, though. You could go through their code looking for the place where it sends a request through Guzzle, then insert a bit of code to log it or something.

I don't know. Can you get the SDK to show you exactly what request it's sending? Maybe it's doing something unexpected. I already complained about the lack of documentation, right?

Now that you've fixed the $operationsObject stuff, what does the code look like?

Nearly every adult site nowadays includes technical information in the response headers or the HTML source that identifies it as such. Research what I'm talking about and detect that, and rather than try to block them entirely, all you have to do is not publish results for those sites publicly.

And what line is 141? Is it the one where you try to echo $response? You can't just output objects like that. Try print_r. But you've got a pretty big bug here: when you create $operationsObject, $operations is an empty array. You add to $operations later but that's too late because $operationsObject has already been created. Move that line until after the array is ready to be used.

Yes, you mentioned that already. What do you mean that porn sites are "indexing on your PHP script"?

FYI it doesn't have to be a PHP object: PHP's arrays will serialize into a JSON object when they are associative (have keys). So you can remove the (object) typecast. Having that array looks right to me. You're definitely passing $operationsObject to the API, right, and not $operations? What's your full code look like now?