netcarver

Not fact-checked, but chatGPT suggests this as a history of short tags in PHP...

Quote

• Prior to PHP 4.0.0, the short tag syntax was enabled by default, and developers could use either <? or <?php to open PHP code blocks.

• In PHP 4.0.0, the short tag syntax was disabled by default, due to concerns about compatibility with XML and other markup languages that use the <? syntax. However, developers could still enable short tags by setting the "short_open_tag" configuration option to "On" in the php.ini file.

• In PHP 5.4.0, the short tag syntax was made optional, and developers could enable it by setting the "short_open_tag" configuration option to "On" or by using the new short echo syntax (<?=) instead of the <?php echo statement.

• In PHP 7.0.0, short tags were officially deprecated, meaning that they were no longer recommended for use in new PHP code. However, they were still supported for backwards compatibility with older code.

• In PHP 8.0.0, short tags were removed entirely, meaning that they were no longer supported in PHP code. Developers are now encouraged to use the full <?php opening tag or the short echo syntax instead.

Does this fit with what you are seeing (given the version of PHP you might be running?)

Also, what version of PW are you running?

1. Is www/site/modules readable and traversable? (Either world readable (r) and traversable (x) or by the user/group you run php as on that server?)
2. Are there actually module files in the site/module subdirectories? (ie, does /home/cinemed/www/site/modules/ProcessHannaCode/ have a readable file called ProcessHannaCode.module?)
3. Any errors at the end of www/site/assets/logs/errors.txt or www/site/assets/exceptions.txt ?
    

In this case, I'd probably just stick to bootstrapping PW from the cronjob script and then using parallel curl.  I was just throwing out some options in case you wanted to explore using something specifically written for async IO like this.

If you are running a CLI-based cronjob for this, then you could take a different approach and try out Framework-X as it's built around react php specifically for this kind of task. Or take a look at react php's http client class if you want to do something more low-level.

BTW, if you do go for this approach, I'd also consider setting a timeout on each connection - so the whole thing should definitely finish within your 60 second limit.

    curl_setopt($handle, CURLOPT_CONNECTTIMEOUT, 5);

3 hours ago, bernhard said:

Eg a cronjob started at 12:00:00 would get its results at 12:00:00 + 100s = 12:01:40 which is really not what I want 🙂 

Sure, but just to be clear, I meant with the parallel curl approach :)

I don't see why you couldn't monitor 100 urls every 60s as long as the machine you are using turns over the sockets fast enough (and has high enough limits on how many open handles it can have etc.)  Your server might already have high enough resource limits to allow it, but if it doesn't then ask chatGPT about things like decreasing tcp connection recycling times (wait timeout) and about linux max open files to see how to up the limits.

Thanks @FireWire

Coming back to PHP, Brent and Roman do an interesting monthly review of PHP things...

I know it's not native PW - but you can use parallel curl for this kind of thing.

$urls = [
    'https://www.example.com/',
    'https://www.google.com/',
    'https://www.github.com/'
];

$handles = [];

$multi_handle = curl_multi_init();

foreach ($urls as $url) {
    $handle = curl_init();
    curl_setopt($handle, CURLOPT_URL, $url);
    curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
    curl_multi_add_handle($multi_handle, $handle);
    $handles[] = $handle;
}

$running = null;
do {
    curl_multi_exec($multi_handle, $running);
} while ($running);

foreach ($handles as $handle) {
    $result = curl_multi_getcontent($handle);
    echo $result;
    curl_multi_remove_handle($multi_handle, $handle);
    curl_close($handle);
}

curl_multi_close($multi_handle);

Ok, are you running mod_security on the server?

Some things to check first:

1. Check the value of the upload_max_filesize directive in your PHP configuration file (php.ini). If the value is set to 2.6MB or lower, it could be limiting the upload size. Increase the value to allow larger file uploads. After making changes to `php.ini`, restart your web server for the changes to take effect.

2. Check the post_max_size directive, it determines the maximum amount of data that can be sent in a POST request. If the uploaded file exceeds this limit, it can result in incomplete uploads or truncation. Make sure this is set to a size greater than the maximum file size you want to allow.

After that, if it still doesn't work, you could try looking at the web server configuration. In Apache, you may need to adjust the `LimitRequestBody` directive in your server configuration to allow larger file uploads.

Runtime-only fields and/or the dashboard module may also be helpful.

I think @bernhard might be on the right track here. If you've changed the charset for the password table from the default, that would likely break things.

Maybe 1) could have a configuration option?

Looks like you might be saving some unvalidated data in the $currentUser there. I'm not familiar enough with Padloper to know if it handles pre-validating posted data like $input->post->email - but if it doesn't you might be leaving yourself open to stored XSS or an email header injection depending on how that field is used later in the code.

And if you switch back to the files session handler can you log in again?

@zx80 There's actually several module's for this in the PW Asset Catalog, but you could always take the purple pill option (am I the only one who wanted a purple pill in the matrix?) and create a textformatter module that people could hook up to their textfields.

If you don't use phpmyadmin, simply relying on Adminer as part of Tracy Debugger on your sites, you can use the `--omit-containers=dba` flag as well to remove that container from your setup...

alias ddpw='ddev config --php-version=8.1 --database=mysql:8.0 --webserver-type=apache-fpm --omit-containers=dba --timezone=UTC'

You can also install adminer in it's own container if you prefer to run that beside your PW container...

alias ddmore='ddev get ddev/ddev-adminer && ddev restart && ddev describe'

Log in to your server via SSH and navigate to the site/assets/logs/ directory and look at the end of the errors.txt and exceptions.txt files. You should see information there about what could be happening on the server.

Simplest way to test is to edit your root .htaccess in the PW install directory and comment out the X-Frame-Options line (just start the line with a hash character '#') and save the .htaccess file, then clear cache and reload the page in your browser. If it works, then this is the issue and you'll either need to add an exception to the .htaccess to allow frame loading from www.domain.com or re-add the line and fix this a different way to ensure the source and iframe both load from domain.com (or both load from www.domain.com)

I know it's a little counter intuitive, but domain.com !== www.domain.com => not the same origin.

Yet it sounds like your server headers are explicitly telling the browser not to load an iframe if it doesn't come from the same origin.

The same origin policy has to match on the domain, port and protocol. So the host page and the iframe source need to be https, on port 443 (by default) on www.domain.com

For reference: and only if you actually need to add an exception to the X-Frame-Options header, you'll probably need to edit the root .htaccess file in your pw install to allow it.

24 minutes ago, joe_ma said:

So far I haven't done anything. Where ore how do I adjust these?

So it probably isn't this then, but for reference these are set either in headers returned by the server, or sometimes in HTML in the head section of your page.  Headers come either from PHP or from the Apache2 set up - in the .htaccess or apache config files.

Have you adjusted the site's CSP or CORS settings?