Leaderboard

It's been a quiet week on the dev branch (mostly), and so this post will also be short. That's a good thing, as it means we are at a stage where there's no new major things to immediately fix or add. Assuming that remains the case, by next week at this time we should have 3.0.200 released on the main/master branch. In next week's post I plan to outline all that's changed since our last master version, 3.0.184, stay tuned and have a great weekend!

Hey everybody, I just uploaded a small textformatter module for wrapping tables with a div container in order to display responsive HTML tables in the frontend. TextformatterWrapTable Processwire wrap table module is a textformatter module for processwire CMS/CMF. It is wrapping markup tables with a div container. wrapping tables with div container simplifies the process of displaying responsive tables in the frontend. The css classes for the wrapper and the table are configurable. .table-responsive / .table by default the module produces the following markup: <div class="table-responsive"> <table class="table"> ... </table> </div> Link to Repository https://github.com/pmichaelis/TextformatterWrapTable

you can set password and other settings in config.php WireMailSmtp/WireMailSmtpConfig.php at master · horst-n/WireMailSmtp · GitHub $config->wiremailsmtp = [ "smtp_password" => "test", ];

So... maybe ask them what they would like to use or recommend in first place and go from there. Depending on the setup you could also look into environment variables which sit in places far away from any web root. Another thing could be a mail account which is only used for that website. Or you use something like Mailgun, Mailjet or similar which is a 3rd party service and therefore all details sit on yet another server. I personally use Mailjet which is configured in a way that only my website can send mails through that account, still everything via SMTP. So... even if someone can get a copy of my credentials they still would need access to the server or the Mailjet account to do anything with it.

@horst the password could be encrypted using the $config->userAuthSalt. For sending an email the module could load the encrypted password from the DB, decrypt it using the config salt and log into the mail account. That way an attacker would have to have access both to the DB and to your config.php file. https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php Though I don't know if it's really worth having that extra...

Triasima, a portfolio management company, asked the agency Contractuelle to revamp its web image. Spiria was the contractor for the site integration. While seemingly straightforward, there were a few challenges ahead, including managing three distinct regions that shared a lot of content: Canada, the United States and the Rest of the World. Two of these regions were assigned a sub-domain (us. and world.). We did not need a multi-site module. Within each region, the visitor has to choose a type of investment profile. One of these profiles could only be selected by the Canadian region. Each profile shares some content but is identified by colour. In short, a small puzzle solved with very little code and CSS. We made extensive use of field repeaters to create a nice administration interface. We have designed "presentation scenarios" that allow the administrator to set up pages as they wish. Only the header and footer are fixed. https://triasima.com

Hello, We have been audited by a security firm regarding a new website in Processwire. The client is a financial firm and insurance companies are becoming increasingly wary of the vulnerabilities that certain libraries represent. The report mentions the two obsolete jQuery libraries that ProcessWire uses for the admin part. Although the visitor or potential hackers are not aware of the use of these libraries (and the report does indicate that the site is secure), the report still mentions a moderate risk when it comes to the administration of the site. In short, the following libraries are requested to be updated to remove these vulnerabilities. .../wire/modules/Jquery/JqueryUI/JqueryUI.js .../wire/modules/Jquery/JqueryCore/JqueryCore.js It might be time to upgrade on this side. Is it possible to do this without causing problems in the administration of the site? I can do my own tests, but I would still like to know the reasons why this is not up to date.

Hi @csaggo.com, Work on price fields to accommodate international currencies is now complete. Decimal styles are now handled correctly. In addition, thousands are also separated correctly (automatically). To help with this, we now have a new setting in Shop / General Settings -> Standards Tab -> Currency Format (please see screenshots below). Price fields will be formatted based on this new setting. Price fields also display the currency symbol if one exists or the currency's abbreviated name. Currently, this is not configurable but I can add this in future if there is demand for it. This also works for variants price fields. Update summary: Automatic formatting of price fields based on the General Settings 'Currency Format' (currency locale). This means, e.g. Canada French versus Canada English is possible; France - thousand separator is space; Germany - thousand separator is period and comma is decimal character, etc. Thousands are automatically formatted as you type. Thousands separator is based on the 'Currency Format'. Decimal style is based on the 'Currency Format'. Currency value validation is also enforced client-side. For instance, if 'Currency Format' is 'de-DE', one cannot use a period as a decimal. Other invalid entries are also prevented, e.g. cannot enter text in this field. Automatic currency symbol placement. Currently, there are no in/decrement elements on the price field. Works with both products and variants (include variant creation modal). Not yet implemented in manual order editing (e.g. fixed discount amount, etc). Download Please use your download link to get the updated Padloper. If you don't have this in your email, please send me an email to resend it to you. Once downloaded, use the files to overwrite the ones in your present install. You might need to refresh your browser cache to clear the older JavaScript files. Version The Padloper version stays the same until #8 is resolved. Screenshots Currency Format (locale) Example: Canada currency formats Example: Germany currency format Edit Product (German Euro is currency) Edit Product Variant (German Euro is currency) Create Product Variant (German Euro is currency) Please test and let me know how it goes. Thanks.

Looks like it happens whn there is only one template that could be used for a new page. Can you try and add another template that doesn't have multilang disbaled?

I did. I checked 3.0.190 and it worked. I checked 3.0.197 and it doesn't work anymore. Somewhere in between it happened.

Tried your copy on my local dev server and it shows the same behavior like in the video. Both languages are there until I save or publish. Then additional langs vanish.

Sorry, at the moment I only have PW 3.0.184 multilang availabe, and there it works as it should. I will try later with a more recent version.

Ah yes, there it is still in plain text too, but also the DB credentials are. But looks like a better solution indeed. Best practise is to have one single config.php file only, that one on the live server. No copies in GIT. And not a plain password in every DB dump! Thanks @fliwire

Thanks, these are valid points. I'm not a module developer, hence the "simple way" in my question. ? No ideas unfortunately. The site is for cyber security experts, their mindset is to minimise the risk when something happens. Their previous WordPress site was compromised so a breach is not an "if", it's more like a "when" for them as they deal with this all day every day.

I'm not sure I understand completely. The password is saved in the DB (module config). If this can be read by someone, you have much more problems then a single smtp password. ? The smtp sending process explicitly needs the password passed in as plain text. So, if we would encrypt it before storing in DB, we would need to decrypt it before sending. If we use hash or salt, or keys etc, they must be stored somewhere (DB?). So, this would not be a "better" solution. Any ideas by you?

Hi @Gideon So, I will prepare something, but it's mostly taking advantage of the Repeating fields.

Hi @Spiria The backend looks amazing. Would you please share how you make it? Gideon