Leaderboard

I'll do that later this evening @horst. However, the reason I chose to make the change I did, rather than the one you suggest, is because different mail modules permit slightly different methods so the WireMailSmtp methods may not work without changing the class. Also, my suggestion will work as a standalone test of WireMailSmtp even if the current class is something completely different (e.g. WireMailMailgun) and the developer is using a different method from WireMailRouter to switch classes.

Hi @MarcC - it should only work that way if you check the "Template resources" option in the Console. If it's happening for you without that checked can you please provide the exact code you have in your template that is resulting in this.

Season's Greetings ProcessWirers! I hope you enjoy the gift of this module, but use with care... TLDR: This module captures changes made in the development environment so that they can be easily migrated to the live environment without needing to specify the changes or write any code. The demo below gives a brief overview. Want to read? Read on. One of the (few) problems with ProcessWire, in my opinion, is the lack of any native way of handling migrations. Given that PW is such a powerful tool capable of sophisticated and complex web-based applications, this is less than ideal. There is a solution, however, in RockMigrations which accomplishes a lot in a controllable way, provided you are happy to specify your database set-up in code rather than via the UI (albeit that the latest versions allow you to grab much of the required code from the UI). If that suits your need, great. Around the same time as the first versions of RockMigrations, I started developing my own UI-based migrations module, which I have been using with reasonable success for some time. I halted development of the module for a while as RockMigrations developed and I considered switching to that route. However, I decided that my module suited me better and that a real improvement could be made if it was effectively automated so that I no longer needed to specify a migration. So that is exactly what it does: after configuring the module, you add a new migration page with ‘log changes’ enabled (which includes determining what types of objects are relevant for the migration) and work on your development system. Once you have made the desired changes (and tested them!) in the development environment, you go back to the migration page where it has magically captured the objects which have changed and listed them in dependency order. You then ‘export’ the changes, which creates json files to be uploaded to the live environment (via Git or FTP etc.), where they are then ‘installed’ to re-create the changes in the live system. The demo below illustrates this briefly. This first demo shows the creation of a migration. The installation demo will be in the next post, because of size constraints. See post 4 for HD video. Video-source small.mp4 There is a very extensive manual which covers all the features of the module, not just this ‘automatic’ method. Available on github at https://github.com/MetaTunes/ProcessDbMigrate and in the modules library here. PLEASE NOTE that this is still in 'alpha'. Do not use in production without fully testing and backing up at every stage. It is quite complex so, although I have tried hard to eliminate bugs, there will inevitably be some left!

You are completely right. Since strftime() is no longer a thing in PHP> 8.1, ProcessWire no longer uses it to format it's dates. Quickly skipping through the code, you can find that Ryan introduced a replacement for strftime() which uses date() and then translates the language-dependent parts using the PW translation system. Here's the section in question: https://github.com/processwire/processwire/blob/3cc76cc886a49313b4bfb9a1a904bd88d11b7cb7/wire/core/WireDateTime.php#L476 Remember, to get gettext-style translations working, you don't need any other modules activated than the LanguageSupport module itself. No need for PageNames and all the others. You can then just add a translation file for the WireDateTime class and translate the months, short months and days to German and you're done.

Thank you da², that was very helpful! I am not yet finished, but I could locate the problems quite closely using your tips.

I didn't even know that was a thing! ❤️

Hi, check this: https://github.com/processwire/processwire-issues/issues/1774#issuecomment-1618267798 EDIT: I missed that, my answer considers that you are using PW language management.

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!

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.

Hi everyone, I know we'd all like to see ProcessWire grow in popularity (maybe not hugely, but just enough that more people know about it which can help to convince clients to go with it). It strikes me as strange that the ProcessWire Github repo still has less than 300 stars - I'd like to see us well over a thousand which should be an easy task for the forum members to achieve. I see so many other projects with lots of stars but for some reason it doesn't seem like it is something we tend to do around here, despite being a very active, friendly, and supportive environment. I also think that starring your favorite modules doesn't hurt either - I think that will also help to increase the visibility from PW and also help out module authors a little as well. If you can show your Github project has a decent number of stars it shows that you are building things that people want which can help you land a job and helps you to convince the client that you and ProcessWire are a good mix. Anyway, if you have a minute to do some starring of PW and your favorite modules, hopefully it will benefit us all a little. Thanks!

Done! Here is the link for everybody to submit a review 🙂 https://www.softaculous.com/review/ProcessWire If you are short on time: https://www.softaculous.com/rate/ProcessWire Both without registration!

Mostly 5 stars on Softaculous, but spot the error in the overview: "ProcessWire is a free PHP5 content management system and framework (open source CMS/CMF) built to save you time and work the way you do." Probably that 'PHP5' doesn't encourage people. Plus it could do with a whole load more reviews - I only spotted @FireWire (the only review since 2019) and @applab (2018). I've submitted a review (and 5* rating) which I hope will be up soon. I don't know how the overview etc. gets fixed.

Nice module, i added this feature to Mystique module next version. You can set a fallback function as a config. Here an example config. Also next version will support most of ProcessWire selectors. You can check or test it from next branch.

Unfortunately, PW only supports one dimension for arrays when using the API to process data. There's been some discussion on this topic at GitHub: https://github.com/processwire/processwire-issues/issues/387