Leaderboard

Hear, hear! ? One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues That repo currently has 289 ideas for improvements, and it would be fantastic if you can find the time to do a quick first pass through the repo and add any comments or questions to the requests, and indicate which ideas you think are the most promising for developing this year. At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207 I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?

@ryan Maybe also some Point to start: The Open Pull Requests: https://github.com/processwire/processwire/pulls

This week I’ve been doing some work on the core, but it’s been a short week with the holidays, so I’m holding off on committing the updates till I can test and tweak them a little more next week. I’ve been working on some upgrades to the core Fields editor (Setup > Fields), as well as some improvements to our Inputfields system, among other things. Next week I’m also planning on working through some of the GitHub issue reports and some other parts of the core as well. With it being Christmas today, I’ve barely been at the computer and I’m guessing not many of you are either, so I’ll keep this short and wish you and your family a Merry Christmas and/or Happy Holidays!

Thanks for your input @horst - turns out this error is new to PHP8 because they changed the behavior of the shutup operator so that it no longer silences fatal errors. I have filed an issue for Ryan with a working solution here: https://github.com/processwire/processwire-issues/issues/1299

Hi @adrian, this is very old legacy code from before 2013 when I joined PW, - and it is from a community member named "mrx": https://github.com/processwire/processwire/blob/master/wire/core/ImageSizerEngineGD.php#L863 So, the referenced SO post seems to be the solution already. Maybe you can send me an image that has this error, so that I can test it. Or would you like to write and test the fix yourself? (As you already have done all necessary work.) ?

ok, well at the risk of hijacking this thread and turning it my dev process (hey, it is dev-talk anyway) ... I've created an app on Cloudways which is a skeleton project with the settings I nearly always end up using on a project. These are (more or less): Modules: AIOM TfaTopt Tracy Debugger TextformatterVideoEmbed TextformatterVideoEmbedOptions TextformatterTableWrapper there are more that probably could go on that list but I think pretty much every site I've done has those. Config tweaks: adding Markup Regions and webp, and disabling session fingerprinting when the site's in debug cos otherwise I keep getting logged out when testing in responsive design mode ... Templates: Basic site layout and then various things like pulling in meta tags / CSP etc, generating a nonce for inline scripts, password protecting the site whilst it's in debug mode. CSS gets pulled in either via AIOM or directly if the site is in debug. For CSS I generally have half a dozen files (definitions / grid / nav / typography and so on) that I've built up over the years but are mostly based on bits of other libraries eg we pretty much have the Bootstrap grid then there's adding a humans.txt file and tweaks to .htaccess (things like Strict-Transport-Security and ahem, X-Clacks-Overhead ). And there's a few application settings like disabling Varnish which never seems to work well for me on dynamic sites. What else ... oh yeah, a .vscode folder in the root of the project set to 400 so I don't accidently upload project settings (yeah that's happened). Now I can just clone that skeleton app in Cloudways and I'm off to a great start for a new project. Looks like cron jobs aren't cloned which is a shame because I have a cron job I normally use to dump database backups (which are easier to roll back than the default Cloudways backups) but that's easy enough to add. And it would be nice to be able to prompt me to change the PW admin user login as well when I log into the cloned site so I don't end up resusing passwords. I'll have a think about that. I'm sure this will save me time going forward - best get on with the sites I was supposed to be building today though....

I'm not sure if this requirement is common enough it that will be considered for the core, but you can easily extend those Fieldtypes by yourself. These are untested, but they should work. It should even be possible to switch an existing FieldtypeText or FieldtypeTextarea to a non-indexed type.: FieldtypeTextNoindex <?php namespace ProcessWire; /** * ProcessWire Text Fieldtype without Index * * Fieldtype equivalent to FieldtypeText but * without creating an index on its text content * to preserve storage. * * Only use this Fieldtype if you will never search * through the contents of the field. * */ class FieldtypeTextNoindex extends FieldtypeText { public static function getModuleInfo() { return array( 'title' => 'Text Noindex', 'version' => "0.0.1", 'summary' => 'Field that stores a single line of text, not indexed' ); } /** * Return the database schema in specified format * * @param Field $field * @return array * */ public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); unset($schema['keys']['data_exact']); unset($schema['keys']['data']); return $schema; } } FieldtypeTextareaNoindex <?php namespace ProcessWire; /** * ProcessWire Textarea Fieldtype without Index * * Stores a large block of multi-line text like * FieldtypeTextarea but without an index on its * text content to save storage space. * * Only use this Fieldtype if you will never search * through the contents of the field. * */ class FieldtypeTextareaNoindex extends FieldtypeTextarea { public static function getModuleInfo() { return array( 'title' => 'Textarea Noindex', 'version' => "0.0.1", 'summary' => 'Filed that stores multiple lines of text, not indexed', 'permanent' => true, ); } /** * Get database schema used by the Field * * @param Field $field * @return array * */ public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); unset($schema['keys']['data_exact']); unset($schema['keys']['data']); return $schema; } }

I prefer to change the pagination style on _init.php, or _func.php, for instance, to use Tailwind classes, using Ryan's modified example:

Thanks, abdus!