Leaderboard

Hi Da2, thank you so much for your help, the problem is solved. I changed 2 things (like suggested in your latest link): <Directory /> Options Indexes FollowSymLinks AllowOverride All </Directory> AND: Go to httpd.conf on /Applications/MAMP/conf/apache and see if the LoadModule rewrite_module modules/mod_rewrite.so line is un-commented (without the # at the beginning) Everything is working again as it should!

Here's the full vhost file for one of my PW sites that uses ProCache. (Note that I've changed the real domain to example.com, and the ProCache string to "ProCache-xxxxxxxxxxxxx".) server { listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2; {{ssl_certificate_key}} {{ssl_certificate}} server_name example.com; return 301 https://www.example.com$request_uri; } server { listen 8080; listen [::]:8080; server_name www.example.com www1.example.com; {{root}} index index.php index.html; } server { listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2; {{ssl_certificate_key}} {{ssl_certificate}} server_name www.example.com www1.example.com; {{root}} index index.php index.html; {{nginx_access_log}} {{nginx_error_log}} if ($scheme != "https") { rewrite ^ https://$host$uri permanent; } location ~ /.well-known { auth_basic off; allow all; } {{settings}} location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map)$ { add_header Access-Control-Allow-Origin "*"; expires 48h; access_log off; try_files $uri $uri/ /index.php?it=$uri&$args; } # Block access to ProcessWire system files location ~ \.(inc|info|module|sh|sql)$ { deny all; } # Block access to protected assets directories location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) { deny all; } # Block acceess to the /site/install/ directory location ~ ^/(site|site-[^/]+)/install($|/.*$) { deny all; } # Block dirs in /site/assets/ dirs that start with a hyphen location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* { deny all; } # Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ { deny all; } # Block access to any PHP-based files in /templates-admin/ location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP or markup files in /site/templates/ location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP files in /site/assets/ location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ { deny all; } # Block access to any PHP files in core or core module directories location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any PHP files in /site/modules/ location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any software identifying txt files location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ { deny all; } # ProCache Rules set $cache_uri $request_uri; if ($request_method = POST) { set $cache_uri 'nocache'; } if ($request_method = HX_REQUEST) { set $cache_uri 'nocache'; } if ($http_cookie ~* "wires_challenge") { set $cache_uri 'nocache'; } if ($http_cookie ~* "persist") { set $cache_uri 'nocache'; } # ----------------------------------------------------------------------------------------------- # This location processes all other requests. If the request is for a file or directory that # physically exists on the server, then load the file. Else give control to ProcessWire. # ----------------------------------------------------------------------------------------------- location / { expires -1; try_files /site/assets/ProCache-xxxxxxxxxxxxx/$cache_uri/index.html $uri $uri/ /index.php?it=$uri&$args; } location ~ \.php$ { include fastcgi_params; fastcgi_intercept_errors on; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; try_files $uri =404; fastcgi_read_timeout 3600; fastcgi_send_timeout 3600; fastcgi_param HTTPS "on"; fastcgi_param SERVER_PORT 443; fastcgi_pass 127.0.0.1:{{php_fpm_port}}; fastcgi_param PHP_VALUE "{{php_settings}}"; } if (-f $request_filename) { break; } } Hope this helps.

Using straight database methods/functions to retrieve data would, unless you process the results differently, just be standard PHP / MySQL requests. You can use the API docs about $database, and take advantage of it, but it's just a ProcessWire way of querying a separate database. The resultant data would still be just that -- data. How you then further process that data and then display it in a template is up to you. Most of what is rendered in a template is up to you, as a developer, anyway. If you're looking for a more ProcessWire-like way of referring to data when using the WireDatabasePDO class (ex: $page->MyCustomTable->row->first('property')), you won't get it, that's just a helper class to standard PDO methods within PHP. Something like kixe's FieldtypeSelectExternalOption might provide you with a PW-like feeling, though I don't know if it's entirely necessary. It all depends on what you want to do with the data from the table, and how you want to interact with it, if at all. If you want to be able to edit it in the admin, and/or create pages from it, then it's not quite as simple, and I'm not sure you'd want to. You certainly can, however. So with the separate database, what is it you'd like to be able to do to, or with, it? Simply display it? Here's another good discussion on this topic, also in the forum...

Good point, guess I was just too lazy 😄 Definitely better, thx!

Maybe first check the global parameter : https://stackoverflow.com/a/21411933 Especially if you didn't create virtual hosts for each site.

Hi @tomasanjosbarao, Thanks for letting us know. I'm not surprised! I'm going to investigate https://developers.facebook.com/docs/instagram-platform/instagram-api-with-instagram-login to see if this will be usable for the same purpose, and if it is, will try and get a new module together before 4/12/24! Cheers, Chris

Thx @szabesz I've corrected this! Now it is in sync with the resulting rrule text 🙂 @monollonom the interface is nice, but also limited as far as I can see? Would the rule shown in the screenshot above be at all possible in your UI? Or what did you want to say with your post?

Hello, Just a few hints, as I do not have more time right now, but I hope this helps: Use URL hooks: https://processwire.com/blog/posts/pw-3.0.173/ an to generate unique URLs, you can get inspiration from this helper method I use, for example: public static function getNewRandomUID(): string { $token = new Password(); $hash = $token->randomPass(["minLength" => 20, "maxLength" => 20, "maxSymbols" => -1]); return self::PREFIX_STRING . $hash . Tools::timestamp(); } Such a function can be enhanced by using uniqueNumber() from WireNumberTools: https://processwire.com/blog/posts/pw-3.0.213/ . I would save them in a database table row as text beforehand, so that they can be looked up when a visitor hits a given URL.

FYI: A catalog of hypermedia-driven websites built with HTMX, Unpoly, Turbo or Twinspark: https://hypermedia.gallery/ Aside from the JS tech behind these sites, eTransfer seems worth trying.

Hello, When reading this, I think it's related with .htaccess not processed, I might be wrong but that's the first thing I would look at. How do you configure the VirtualHosts of each site? Is there a directive AllowOverride? https://stackoverflow.com/questions/35251032/how-to-create-virtual-hosts-in-mamp

Does anybody of you guys have some numbers in how much faster PW gets when using nginx instead of apache?

I would also like to know! Tracy stopped showing the unwanted behavior after the template code was updated. So, I wonder if Tracy is not completely isolated in the case of the console, and in fact attempts to access the body property as it comes out of the template processing. This seems like it could be meant as a convenience. Just an idea though! I guess it would have been nice to know it was doing that. 😄

@MarcC If/When you get a chance to look into it again: How was Tracy duplicating the behavior if it was template-based rendering?

Very well done! Looks great. What does it show if "every 1 day" is selected? I also thought of hiding those settings based on the frequency dropdown, but I realised that they can be used in a combined way as I showed above. Not sure what to do about this. Sometimes it might be preferable to have more options, sometimes it might be better to have a slicker ui...

Sorry for the disturbance in the Force...

At first it was @szabesz’s suggestion that made me post this, because of the way things are handled in the calendar app: there’s no “In Months”, just “Each” and it only appears if the frequency is “Every month” and so on... I liked it this way because of how the ux “difficulty” (let’s say) is incremental. But in the end I think your way of doing actually makes more sense (and you are right that it’s more limited in my case)... so you can dismiss my post 🙂

I'm just reading the docs: https://help.instagram.com/502981923235522 https://www.facebook.com/help/instagram/138925576505882?helpref=faq_content I haven't read anything about any restrictions that would prevent a "normal Instagram account" from being converted into a business account, yet. As I read the documentation, this seems to be the case. https://developers.facebook.com/docs/instagram-platform/instagram-api-with-instagram-login/overview

Hi @DV-JF, So the limitation is that it isn't for use by personal accounts? For our use cases, I think every one is a business (and should have a business account), so I'll still explore it, but I can understand that'll be frustrating for those using this module for personal projects. I don't think it takes much to switch to a business account - both the band accounts I have access to on Instagram are business accounts, I think it is just a case of specifying that? Or at least it was when these were set up years ago. Given the maze of Meta requirements it wouldn't surprise me if you need to submit yearly accounts to get a business account now... Cheers, Chris

@tomasanjosbarao Thank you for sharing this info and thank you – @nbcommunication – for further investigation. It would be great to see a new module👌 The first limitation a I see is this: Source: https://developers.facebook.com/docs/instagram-platform/instagram-api-with-instagram-login

Hi Da2, thanks for your suggestion. I'll have a look into it and will let you know.

Thanks a lot @szabesz, that definitively enlightens me. I’ll give it a try when I come to this part. Again, thanks!

@bernhard Just a small note regarding the label "On months". It would be grammatically correct to use "In months," in my opinion. https://langeek.co/en/grammar/course/567/on-in-month It is because "on" would be correct only if the word "month" were used with a specific day, as the linked article explains. Since the months stand alone in this case, "In months" seems to be the correct choice.

On further investigation: One of the site's main templates was using a preg_replace function to automatically convert plain email address text into links. The situation has been remedied by removing this until I can look into it further and decide whether to modify the code. No more duplicate prefixes! Hooray. I actually stumbled upon the issue while checking where I was using the separate HTML Purifier class in the template code. So a bit of luck helped in the investigation... Thanks all for your ideas & input!

I have more than a dozen PW sites running on CloudPanel, which uses NGINX. I’m using the basic PHP site configuration CloudPanel offers, and it works out of the box. I’ve added a few rules mentioned above in this thread for extra security (they’re not actually needed for running PW), plus ProCache rules. Not sure if these settings can be copied as such in a standard NGINX setup that does not use CloudPanel, but I could post them here if you want.

@MarcC Got by any chance the module EMO EmailObfuscation installed? I once had the same problem and it was EMO.

I removed the header in simple mode to be even more compact: In advanced mode the header will be shown:

That's definitely an interesting one based on what you've already provided. My first thought would be some sort of custom TextFormatter but you've already tried removing that. Even more confusing considering the rendering within TracyDebugger is showing the duplication. Silly question: You weren't working on a local/dev version but checking updates on a live/production version, right? ProCache was most definitely completely off, and any saved caches were cleared? Field-level caching was not enabled on the body field? Is the body field a standard textarea/CKEditor/TinyMCE field, or is it part of a Repeater(Matrix)?

WireMailRouter was set to use WireMailSmtp as primary method, but (if a from and to is specified in verbose settings) WireMailSmtp ignores the test attempt if it is not the WireMail class name: $mail = wireMail(); if($mail->className != 'WireMailSmtp') { $dump = "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; } else { So basically the full test will not work if WireMailRouter is installed - only the plain connection test. My suggestions are: The config screen should make it clear that verbose debug settings will not work if WireMailSmtp is not the WireMail class and need to be empty to test the connection only, or that the test should temporarily set the WireMail class to be WireMailSmtp - something like: if($from && $to) { // do a verbose debugging if(!$subject) $subject = 'Debug Testmail'; if(!$body) $body = 'Debug Testmail, äöüß'; $mail = wireMail(); $dump = ''; if($mail->className != 'WireMailSmtp') { $wireMailClass = $mail->className; $this->config->wireMail('module', 'WireMailSmtp'); $mail = wireMail(); $dump .= "<p>Currently installed WireMail class is $wireMailClass. Testing with WireMailSmtp, then reverting to $wireMailClass.</p>"; } $mail->from = $from; $mail->to($to); $mail->subject($subject); $mail->sendSingle(true); $mail->body($body); $dump .= $mail->debugSend(3); if(isset($wireMailClass)) $this->config->wireMail('module', $wireMailClass); } else { // only try a testconnection Personally I'm more inclined to (2), but does anyone else have a view?

Meta is going to disable Instagram Basic Display API, starting on December 4th, 2024. I'm trying to figure out what to do next. (Two weeks ago I was trying to use this module for the first time, for a client of mine, and the process of setting up an app with them is nuts, with the amount of data they ask from us and the confusing and complex interface of their developer thingy...) Thanks for the module, Chris.