Leaderboard

Hello da², I still stand by my comment in that you are in compliance, a warning is not the same as an error, and attempting to circumvent the current processing of text for the sake of clearing a warning may cause more harm than good. That said, this topic came up back in October, and the linked topic should provide you with possible workarounds, if you decide to take them: EDIT: For any modules that output their own HTML (ex: InputfieldText's ___render() method), you'd need to find, and then override the module's own output method to fix; or setup and run all of your generated HTML through a post-processor.

Version 2.9.0 changes the syntax for repeater fields from this: $rm->createField("my_repeater", "repeater", [ 'label' => 'Test', 'repeaterFields' => [ 'title', ], 'fieldContexts' => [ 'title' => ['label' => 'foo'], ], ]); to that: $rm->createField("my_repeater", "repeater", [ 'label' => 'Test', 'fields' => [ 'title' => ['label' => 'foo'], ], ]); This might be a breaking change in your system so check before updating ?

I just tested this a bit with HTMLPurifier, and (at least in quick testing) was unable to prevent it (as far as I could tell) from removing the HTML equivalent of the character (using &shy;, or pasting a rendered version of it in directly). Searching the internet as a whole doesn't seem to give much specific information either. Since &amp; worked but &shy; did not, I'm not entirely sure what's going on internally without auditing the underlying code (for HTMLPurifier), and would likely have to do the same for CKEditor and/or ProcessWire. If you change the field from a WYSIWYG interface to a simple textarea, does it work as expected? If so, you might need a CKEditor plugin for the soft hyphen, but I'm simply guessing. In the one Stack Overflow topic I found, most people actually recommended using <wbr> over a soft hyphen - why do you feel it's "kinda outdated"? With the exception of Internet Explorer 11, it has full browser support, and if it works right now (whereas soft hyphen does not) then that's less time you'd need to worry about it. As for the lack of a hyphen, there might be some CSS solutions there, but I'm unsure how well they'd work out. One last thought: I didn't test this in ProcessWire myself -- are you sure it's not just converting the text of &shy; to \u00ad in the database?

The difference with Admin Actions is that it's always going to be PHP code and also it's not being used to edit code, just view it. I did look at Monaco when I was initially developing the Console panel and came across some issues I couldn't resolve (although I don't remember what they were now). I could probably get away with only packaging one theme and remove the config options, but because I think so many of use the Console panel so much, I think giving users the ability to match the styling to their preferences is a pretty nice bonus. As for language syntax highlighting / linting etc - there are certainly options that could be removed like elixir, csharp, and lots of others, but I wouldn't want to limit to just PHP, HTML, CSS, JS. What if someone is working in latte or twig or coding JS in CoffeeScript or they are connecting to a separate Postgres DB and could make use of (mode-pgsql), or editing some SVG code (I sometimes use the Console panel for this). Keep in mind that the entire Tracy module zip file is only 3.5MB (https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip) so even if I removed all the extra Ace files, it might get down to ~1MB. I am just not certain I want to remove functionality that someone might use for the sake of a couple of MB. Note that I used to do exactly what you are asking for: https://github.com/adrianbj/TracyDebugger/tree/3181668f6841ae9f75a9fe49e6e8331ab0c69fc4/scripts/ace-editor but as I mentioned, each time I update it, I have to manually copy across the new files rather than the entire set.

As someone who does a lot of local development, sometimes with no Internet access or extremely slow one (e.g. while travelling), this would not be preferable. Having everything available locally guarantees that things work as expected. Also it guarantees that the version I have can't be compromised by malicious actors. Assuming, of course, that it was safe in the first place ? Personally I don't have an issue with Ace, but if Monaco (or something else) does similar things with less overhead then why not ?

--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.

Hello @bernhard, as posted in the other thread, I tried adding the Latte Tracy Bar to RockFrontend. Just Added this to the RockFrontend.module.php: // Top of the Module add the LattePanel Class use Latte\Bridges\Tracy\LattePanel; // Add inside the "protected function renderFileLatte($file, $vars)" // After "$latte = new Engine();" add this to initialize the LattePanel if($this->modules->isInstalled("TracyDebugger")) LattePanel::initialize($latte); After that you have the LattePanel in Tracy ? I have not been able to detect any problems so far.

140 commits, 55 resolved issues, dozens of new features, eight contributors, and five new pull requests make yet another great new version of ProcessWire. This week I’m happy to announce another new main/master branch version of ProcessWire, version 3.0.210. Like most main release versions, there is a lot here. This post covers some of the most notable additions and improvements— https://processwire.com/blog/posts/pw-3.0.210/

Thx @zoeck https://github.com/nette/latte/issues/287#issuecomment-1377083605

After upgrading to PHP 8.1 I get this message when sending mail: Deprecated: Function strftime() is deprecated in /Users/XXX/Sites/processwire-ui3/site/assets/cache/FileCompiler/site/modules/WireMailSmtp/smtp_classes/email_message.php on line 675 This is no surprise - strftime() needs to be replaced in the future. It's still working fine at the moment, though. See email_message.php, Line 675: return($this->FormatHeader("Message-ID", "<".strftime("%Y%m%d%H%M%S", $seconds).substr($micros,1,5).".".preg_replace('/[^A-Za-z]/', '-', $local)."@".preg_replace('/[^.A-Za-z_-]/', '', $host).">")); I am afraid to fix this line by myself... it looks complicated ?

I honestly haven't even been thinking about it, but I actually had a case where I used this - without "renderIf". But this is actually more of a workaround, as I simply include an empty latte file (the "blank.latte" file is displayed in the Tracy Panel) {include $pages->find("template=test")->count() ? "test.latte" : "blank.latte"} I think that is "a bit renderIf" in latte syntax ? Two templates have to be specified at all times, otherwise an error will be displayed. It would be very cool if it would also work with a single template... I think currently you only have this benefit ?

Yeah I understand that and I agree, but I was asking for benefits other than that? I thought there are maybe other benefits as well ? I'm always happy to hear that (1) anybody is using my modules at all and even better (2) if they are using it differently and (3) share their findings so that I can see other approaches ? I could use {include ...} instead of $rockfrontend->render(...), but the non-existing early exit is really a show-stopper for me. Do you have any other approach to that? I don't see a drawback with the panel (that's why I added it). It's just the missing renderIf() or early exit feature that I lose when using {include ...}. But using {include ...} is necessary to get a meaningful latte panel. I'm looking forward to hearing what you find out ?

I agree that it's not a major issue, but it would still be nice to slim down the total TracyDebugger size because it's a module that receives frequent updates (thanks! ❤️) and so I'm downloading it regularly. Ace makes up approximately 80% of the total TracyDebugger size. Could it maybe be loaded via a CDN? https://cdnjs.com/libraries/ace Also, I've heard good things about Monaco (possible replacement for Ace): https://cdnjs.com/libraries/monaco-editor

Hey @bernhard - any particular reason you want it disabled? That said, you can do what you want very easily by adding this in your URL hook. \Tracy\Debugger::$showBar = false;

Hi @szabesz - probably not, but I didn't want to limit users to specific themes and I also didn't want to remove syntax highlighting and linting for languages just because I don't think they will be needed. I guess my main reason though is that it's much easier for me to just update the entire set without needing to limit updates each time and in the scheme of things, I don't see 11MB as an issue given that one high resolution image upload might easily equal this. Keep in mind that none of these are loaded except those that are needed. Do you have a specific need to reduce it?

@zoeck I wonder if it could make sense to make our own debug panel for RockFrontend that keeps track of all $rockfrontend->render() calls (and also renderIf)?! Is the latte debug panel helpful for you as is? I think for me it has more drawbacks than benefits. What are actually the benefits other than to get a list of rendered latte files?

Yes absolutely. I have this kind of monstrosities in my markup: <?= IntlDateFormatter::formatObject( new DateTime(date("d.m.Y", $event->date_event)), "EEEE, dd.MM.yy", 'de_DE' ); ?> Which works perfect but is a bit hard to read and to maintain (in fact I never want to touch this code again...). If you are working with a predefined date format all over your site it really makes sense to preconfig that.

Nice. I’m all for one-liners (at least for something like formatting…), but I find the whole IntlDateFormatter business a bit verbose. I like to keep pre-configured instances of the things around, for example on $config, and just call something like $config->dateFormatter->format($page->cooldate) Not sure if $config is a good place for this, and I have no experience doing this on multilanguage sites, but I imagine you’d be able to prepare the instances according to the user’s language and never have to worry about it again.

Hi @alexm, Finally, fixed in Padloper 008 released today!

I agree, you have to use the IntDateFormatter class, like @Jan Romero mentioned. Have a look at this thread, I made a few examples how to use the IntDateFormatter as one-liner, etc.

The new thing in PHP for this is the IntlDateFormatter class: $giornoDellaSettimanaFormatter = new \IntlDateFormatter('it_IT', \IntlDateFormatter::FULL, \IntlDateFormatter::FULL, null, null, 'eeee'); echo $giornoDellaSettimanaFormatter->format($page->getUnformatted('data')); //Domenica https://www.php.net/manual/en/class.intldateformatter.php

What's about a cache busting param with the last modified timestamp of each image variation file? /site/assets/files/1/basename.300x0.jpg?ts=1565267238

Just one additional comment to @LostKobrakai's great reply. HTML5 sessionStorage is basically the same as HTML5's localStorage except that it is only stored for the current session whereas localStorage is kept forever unless intentionally cleared.

The text is talking about server side session handling. The default in php is to store files in the filesystem with session identifiers, which historically was more prone to security issues on shared hostings than the database. Most services I use nowadays got their filesystem permissions properly under control though, so this hopefully is a thing of the past. Php does also support other storages for sessions out of the box like redis or memcache. ProcessWire also comes with SessionHandlerDB, which stores the session identifier in the MySQL database next to all the other data it needs to store. This is an easy solution, but makes your application more difficult to scale independently depending on the load you get. $session is the API variable, by which you work with said php session of users in ProcessWire. Everything mentioned by now is totally unrelated to client side storage like the html5 sessionStorage. This has the name "session" in it not because it somehow relates to server side session handling, but because it lasts only for a certain browser session a.k.a. it's wiped as soon as you close your browser. It's just a property for the "Storage" it provides in terms of expiration of data. Depending on what you want to do server side sessions and the sessionStorage of your browser can both provide a solution, but ultimately they work vastly different and you need to decide based on the tradeoffs what you should ultimately use.