Leaderboard

Hi everyone, I just committed to new versions. 4.22.23 - updates Tracy core to 2.8.10 4.23.0 - updates Tracy core to 2.9.0 I think everything should be fine in 4.23.0, but the new Tracy core 2.9 major version means that Tracy works without PHP sessions. This means that I was able remove several hacky workarounds to make this module compatible with PW's SessionHandlerDB module. I think I have everything working as expected, but wanted to also release a version with what I assume will be the last version of 2.8.x of the Tracy core. Please let me know if you find any issues with the new 4.23.0 version and if you have any problems that I can't solve quickly, you can always drop back to 4.22.23. Happy holidays!

Is this what you want?

The core could maintain a list of checksums for its own site profiles, which would restore security to prev. state even with downloads involved. For third party profiles there could be a warning about the tradeoffs involved.

Thanks — it's been a few years, but I would expect results to be somewhat in line now. Though we can always run a new poll if that makes sense ? In my experience... experienced users are likely to use the blank profile or have a site profile (or a prebuilt starter site) of their own, while new users would find a simple starter site profile — one that looks like a real site but is still unopinionated — valuable. Regardless of whether we end up bundling a new "simple" site profile, I think this would be a good idea. Assuming that it can be done in a way that makes it reliable, flexible, and most importantly secure. As Ryan pointed out, installing site profiles from the directory has some interesting security implications: if they can be installed during the normal install flow, any issue with them will directly reflect to ProcessWire itself ?

Whether it's via RM or some other method, having proper support for handling migrations in the core would be huge ? One thing I miss from WordPress is the ability to define data structures programmatically. It's nice to be able to store such definitions in Git, share them among developers, modify or roll them back with ease, and then deploy to any number of environments automatically. The contexts are of course different: custom fields and custom post types have no real table structure(s) per se, so certain things are very easy, while others are very hard (or inefficient). Pros and cons ? From my point of view RM and Composer both have their use cases, and neither can replace the other. Where RM and Composer overlap is mostly just installing modules and perhaps managing core updates. While one can run all sorts of stuff with scripts or installer modules in Composer, it's not really intended as a tool for creating, implementing, or rolling back migrations.

Just wanted to mention that this is a one-liner using RockMigrations: <?php $rm = $modules->get('RockMigrations'); $rm->setPagenameReplacements("de"); // or the even newer setDefaults: $rm->setDefaults([ 'pagenameReplacements' => 'de', // de is default // 1 is default and means consistant click behaviour on inputfields // see https://github.com/processwire/processwire/pull/169 'toggleBehavior' => 1, ]); I'm really not a fan of site profiles, so removing them from the installer is a welcome change for me ? IMHO if we put energy in that direction it would be a lot better to think about better automation than about adding more site profiles... This is already possible using RockMigrations (sorry, self-promotion again): <?php // site/ready.php // Demo "Site-Profile" using RockMigrations $rm = $modules->get('RockMigrations'); $rm->installModule('FieldtypeRepeater'); $rm->installModule('HannaCodeDialog', 'https://github.com/Toutouwai/HannaCodeDialog/archive/master.zip'); $rm->installModule('ImportPagesCSV', 'https://github.com/ryancramerdesign/ImportPagesCSV/zipball/master'); $rm->installModule('InputfieldPageAutocomplete'); $rm->installModule('LazyCron'); // you can also set module config easily $rm->installModule('TracyDebugger','https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip', [ 'guestForceDevelopmentLocal' => 1, 'forceEditorLinksToTracy' => 1, 'editor' => 'vscode://file/%file:%line', ]); // multilang: translate default language to german $rm->setTranslationsToLanguage("https://github.com/jmartsch/pw-lang-de/archive/refs/heads/main.zip"); $rm->addLanguage("en", "Englisch"); // add english as second language I'd love to see RockMigrations (or something similar) in the core one day. It makes developing modules so much easier, more fun and also faster. And of course it helps you in all your CI/CD workflows making your setup more professional, more robust and reusable! It can be used to automate anything you want. Just like shown in the "site-profile" example above. You'll not only have much more freedom about your setup, you'll also get the latest version of all your modules... PS: Maybe something similar could also be done using composer, but as soon as you want to set module settings and/or create fields/templates etc. composer is out ? PPS: My old project PW Kickstart from 2018 could also be used for some inspiration...

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub. The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile. I may do a little more with it and rename it to be site-basic or something, and then have an even more trimmed down site-blank in its own repo as well. I'm not yet sure about that, so will do a little more with it next week also. I also went through each of these site profiles and cleaned up a few things, corrected old and outdated links, and updated a lot of text in readme files and such. I think a lot of the more experienced users would also prefer not having extra profiles included in the core as well. This update came at the request of the community a few months back (I think it was Robin S. that requested it, but not positive). It's not like any of the current site profiles have a lot of bling or marketing value, as they really are more just technical examples and starting points. So I think it's kind of a win/win to trim down the core in this way. Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim. The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at. Thanks for reading and have a great weekend!

As this doesn't interfere with non-composer users... sure. Can make life easier. Another 2 cents: All modules (maybe only those with some kind of frontend/GUI) should have specific permissions to allow them to be part in roles in more advanced setups.

I think all modules should be installable via composer as it makes everything more maintainable. There is an composer installer for ProcessWire modules, so you just have to add a composer.json file to your module and the module will be installed in the right directory. Here is a good explanation One advantage of installing modules via compoeser is, that you can version control your composer.json file or have different modules based on your environment:

I have added a request "findRaw should have support for joining parents and references" (and also for getting option field titles) here https://github.com/processwire/processwire-requests/issues/427 @adrian @thetuningspoon

https://processwire.com/modules/inputfield-runtime-only/ ?

It works fine for me. If you don't have access to the Pro Fields forum, maybe try sending a message to @ryan

Just a hunch, but are you using the HTML or JS based date picker? If it's the HTML, then the browser you're using could potentially have a bug. A while ago there was a bug in Safari that didn't let you pick dates in December if I recall correctly. If it's the JS base date picker, I've no idea. Unless you've set the minimum date higher than what you tried to pick.

Hello, @Frank Schneider! You can use $ts_entry->of(false) instead of $ts_entry->setOutputFormatting(false).

A few thoughts: $config->userAuthSalt was changed a database update broke something (update through your hosting company) a browser extension interferes a CDN interferes (Cloudflare is really good at it) you use the wrong user name you changed settings to login with e-mail That's it for now.

Have a look at the docs ? Implementing a language switcher https://processwire.com/docs/multi-language-support/multi-language-urls/#language-switcher

HELLO! I always struggle adding additional functionality, buttons and other settings to the CKeditor and I guess other people might have the same issue at times. For those who are CKeditor aces would you share your settings in this post to help others with what I guess should be a simple task to extend the default settings. Extra color select and text formating toolbar Format, Styles Bold, Italic, Underline, -, RemoveFormat TextColor, BGColor JustifyLeft , JustifyCenter, JustifyRight, JustifyBlock NumberedList, BulletedList, -, Blockquote PWLink, Unlink, Anchor PWImage, Table, HorizontalRule, SpecialChar PasteText, PasteFromWord Scayt, -, Sourcedialog extra allowed content small[*] section font[style] span[style]{!color} code[*] custom config options colorButton_colors: ec4626,ffde43,00aaeb,004a87,7b9320,ffffff extra plugins colorButton

Only if you tell it to: https://curl.se/docs/manpage.html#-L You’ll also have to increase the maximum number: https://curl.se/docs/manpage.html#--max-redirs

There was a poll in 2017: https://weekly.pw/polls/#which-site-profiles-should-be-bundled-with-processwire Personally I only use the blank site profile. But for beginners one starter site profile would be necessary. I don't think there is a need for multiple site profiles, but that is just my opinion. Other CMS offer two separate downloads (one blank and one starter download). This could also be an option.

What is your monitor size?)))

Solved the issue. Found the following issue in a post from 2015 using some Google search that described a similar/same problem. I was able to solve the issue by logging in as a different user, checking the checkbox, and then saving the page. After that the superuser role was then allowed to set/save the checkbox. Odd issue. I created two fields, one text and one checkbox. I was able to set the value of the text as a superuser but not the checkbox. Solution is to log in as a different user with access to this field, set a value, then logout and then login as the superuser which will then allow the value to be saved.

I also need support for joining parent fields!

Just to go against the grain a bit: Those modules are way, way overkill for 99% of sites. Just looking at the screenshot in the Seo Maestro thread, all those options would confuse most of my clients. Who really wants or needs to manually edit the change frequency of a single page? Some of those options should also be generated automatically (Locale, based on the current language) or set globally (Site Name, for example). I get that you can control which fields to show and that it's kind of a framework which you can use for all kinds of sites. But in my experience, showing five screens of SEO settings on every page is the best way to get clients/editors to be scared of them and never use them. Three fields - title, description, preview image - are all you need most of the time. KISS. I would use external tools for this. There are many tools that are much better at this stuff than Yoast, and they look at the page as a whole, not just the body content. For example, at work we have at some points used the following tools among others, in no particular order: Ryte, Seobility, Semrush, Sistrix. And many more ...

Here is another snippet that I use to get rid of unwanted table properties: // Remove unwanted attributes from tables CKEDITOR.on('dialogDefinition', function(ev) { var dialogName = ev.data.name; var dialogDefinition = ev.data.definition; if (dialogName == 'table') { var info = dialogDefinition.getContents('info'); info.remove('txtWidth'); info.remove('txtHeight'); info.remove('txtBorder'); info.remove('txtCellPad'); info.remove('txtSummary'); info.remove('txtCellSpace'); info.remove('cmbAlign'); var advanced = dialogDefinition.getContents('advanced'); advanced.remove('advStyles'); advanced.remove('advId'); //Id attribute advanced.remove('advLangDir'); // writing direction advanced.get('advCSSClasses')['default'] = 'uk-table'; //set default class for table } Put this code inside your custom config.js Best regards

Hi, Got it solved myself. I use $p = $pages->find("template=repeater_yourRepeaterField, limit=10") rather than $p = $page->yourRepeaterField->find("limit=10"). Gideon

I just had an issue with a site where end users were pasting content from Word. There is a Paste From Word plugin, but that still leaves a lot of formatting and overrides the paste as plain text. To resolve this I did the following: Custom Config Options forcePasteAsPlainText: true Remove Plugins I added pastefromword to the end of the list already there.

What do you guys do about multi-language versions of PDF documents stored in a files field? I want the correct language version of each doc served on the frontend based on the language selected by the user. Do I make use of the Language alternate fields in this case, or do you guys upload different versions to the one files field and have some sort of naming convention, eg "mypdfname_dutch.pdf" etc and then add the logic via the template API to server the correct version? Thanks for any advice.