dotnetic

@teppo I modified my post about the stale plugin. You can configure the label and if the issue should be closed automatically.

I also want to bring GitHub Apps - Stale to your attention @ryan. This bot adds a "stale" (or whatever you configured) label to all abandoned issues after a period of inactivity. After another period the issue is automatically closed (configurable). If a user or the original creator posts a comment, then the stale label is removed and the issue persists. Don't know if this is a good or a bad thing, but wanted to mention it.

That has to be me, because some/many other Open Source repositories handle requests this way, and thats how I have done it there. Let ProcessWires users decide, what is most important to them. Also the thumbsup/+1 is a better way to handle this instead of a "I also have this issue" comment, because else you would get nagged by the comments, and they provide no additional value. This is a good step to let the community know that their word and wishes also matter and they play a role in ProcessWire development. The README and issue/request templates should reflect this procedure.

The Page Lister (a centerpiece of PW) is also in need of major improvement IMHO. The icons are not always in the same place due to page titles of different lengths, which is very annoying and distracts a good workflow. A tabular representation or other optimized view, would be better suited here. Here, again, everyone may have a different preference, so an option of which display type to use would be a good idea. This has been mentioned here before. I would be willing to work on a proposal for an optimized layout. Moving entries in the page lister, doesn't work very well and it's cumbersome. I found a great Tree JavaScript a while ago that implements drag and drop much better http://www.treejs.cn/v3/demo.php#_307 and was actually going to work on integrating it to PW, but unfortunately didn't have enough time. The looks of that script can be completely customized. Then I didn't know if it was worth it, since I know that many PR's just never get integrated and I also lacked the time. I had made first attempts, but noticed that the PageLister is very extensive and nested.

One of the things that bothers me about ProcessWire is the integration of the community into the development process. It is not clear which features or ideas will be implemented and if and how you can influence this decision at all. For example, it would be conceivable that within a period (for example a quarter) you look at which Github issues have the most thumbsup and then fix or implement them. If there are too many features, or they have the same number of thumbsups, you could also make a poll in the forum, what the community would like to have implemented faster. The pull requests sometimes are not integrated for years. Even if a control or a rewrite would be necessary for this, it would be good to have a feedback if the PR is "under consideration" or "won't merge" or "working on it" or a comment. Because the way it is now, it seems like the PRs are just decaying unseen and there is no point in working on this open source project. Ryan wrote: My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. It would be nice if this was also listed in the Contribution Guidelines https://github.com/processwire/processwire-issues/blob/master/CONTRIBUTING.md These guidelines are also the place to say how new ideas or fixes are handled and under what conditions they are integrated. If Ryan discloses his criteria that he has as a requirement for features, enough developers might follow those guidelines when creating a PR. After all, it would be great if there were a few selected contributors and they could then merge PRs, or at least do a pre-review, so that Ryan has an easier time integrating them later.

Wow. So many great input here, but instead of making one large post, I split this up to multiple ones, so I can talk about more features and wishes specifically. While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management. Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. I had the idea to implement editor.js some years ago (but did not done it yet), and think it would be a great addition to ProcessWire, because building blocks are something requested by one large client of me. He now has the ability to add content blocks with Repeater Matrix, but I think its cumbersome and not very intuitive, and has its drawbacks. That is the same for every page builder and content block solution, that I have seen here on the forums except FieldtypeEditorJs. Everything in my opinion and please don't feel offended. Editor.js and the Bard fieldtype from Statamic (which is extended in V3 of Statamic, Bard is based on ProseMirror) are very good, because they save content not in HTML (but you can, If you want to) , but as structured data, which then can be rendered via partials however you like (that's how I do it in Statamic). As an explanation you can read my post The FieldtypeEditorJs : Preview of a productivity fiedltype for editors. - Module/Plugin Development - ProcessWire Support Forums is a first good looking implementation of this fieldtype, but is not released yet. Maybe you can talk to @flydev 👊🏻 about integrating it into the core. I think there would be enough people to sponsor this feature. I do not think, that we need another website page builder which is responsible for the whole layout. Block based contents would be enough in my opinion. But that's just my two cents and I know, that opinions might differ on this.

Hey @flydev 👊🏻. Now that half a year has passed, any news ? A release date? Will this fieldtype be free or paid?

You could use if(!$page->isUnpublished()); // take note of the ! to negate the command // or if($page->isUnpublished() !== true)

I use a combination of gulp and BrowserSync for live reloading. Maybe take a look at my setup repo jmartsch/acegulp4: A set of gulp tasks with JS transpilation, webpack, SVG Sprites and minification (github.com) It has the following features: Gulp 4 Webpack 5 with Babel SVG Sprites with minification Browsersync with proxy for existing webservers File revving JavaScript transpilation with Babel and minification SCSS compilation with minification and sourcemaps If you like it, leave a star, or ask me questions. Edit: If you didn't manage to get BrowserSync working, the cause could be, that you have to proxy your already existing webserver.

I did Page title (Multi language) field empty after core upgrade to 3.0.165 · Issue #1291 · processwire/processwire-issues (github.com)

I did an update from core version 3.0.123 to version 3.0.165. I have a template "stelle" with a Page title (Multi language) field. As soon as I update the core, the title field is empty. When I revert back to the old core version, the field is filled out again. @ryan can you help please? What is happening?

I upgraded to PHP 7.4 for several projects. The only errors that occured were "array and string offset access syntax with curly braces is deprecated" and I changed it in the according 3rd party (or self-written) modules. Personally I would wait until ProcessWire and modules are known to be compatible with PHP 8. Same as Moritz said. Take little steps instead of one large one.

I remember this issue, which could be related: make the fallback optional if pagefile->url is smaller than webp · Issue #903 · processwire/processwire-issues (github.com)

But also if someone provides updated translations or improvements here I will likely integrate them as soon as I have the time.

A PR would be the easiest and least time expensive way for me. This was one reason for me to provide the language helper repo https://github.com/jmartsch/processwire-language-pack-helper, so translations could also be tested in a real environment. Another way would be to fork and modify the file directly in github (it has a nice file editor) and then make a PR. I will then check and merge the PR @LostKobrakai @bernhard