dotnetic

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

@NooseLadder That would require a paid subscription of ngrok or a DynDNS setup, or you could setup a local DNS server which resolves hostnames in your local network. You could even add the static IP address of your local webservers computer to the .hosts file of your other devices (depending on the device it's possible or not). I would recommend to open a new thread for this or search on various sites like servervault. If you would like to test your website(s) on different devices, I would also recommend BrowserStack which I also use.

I just clicked the link, that the OP provided. I also tried different browsers (Firefox, latest Edge, latest Chrome) . All show an SSL error. I am surfing from Germany and via Unitymedia/Vodafone.

Yeah, thats why I left it and updated the instructions: https://github.com/jmartsch/pw-lang-de/blob/master/README.md

Thanks Moritz. My method described that you don't add the official pw-lang-de repo as a submodule, but the forked repo instead. Your method adds the forked remote to the submodule so they can push to their remote. I think I will mention both ways in the README, so one can decide which route he takes.

The problem is not the setup of the dev environment. Composer would be just another way which saves you one or two steps that you would have to make manually (but I like the idea. I will consider it). I tried to figure out how a contributor can submit his changes to the pw-lang-de submodule. Because he clones the pw-lang-de repo as a submodule he won't be able to submit to this repo. So the steps that I thought of are: Fork the pw-lang-de submodule on github so you can submit to it and make a PR. Then you could simply clone the processwire-language-pack-helper (dev environment) and add the forked repo as a submodule. After making changes you can make a PR from your forked submodule to the german language pack pw-lang-de. What do you think about this?

SSL error: Site is not safe

Site is not reachable

My ProcessWire environment for language packs provides an easy way for translating your language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. If anyone is working on a language pack, let me know how it works out, or if you need changes or help.

I really don't know, but I don't think so. So I changed it and also months and years

New release for latest stable PW version 3.0.164

@bernhard Sadly the suggested changes to the image manipulation are not possible, because I can only translate the word "rotate". It is not the whole string that can be translated. I have seen you have already opened an issue for a change on github

Thanks @bernhard for the improvements. I will implement them shortly. Good suggestions!

I also did not know, that it worked like that. But I am not sure about using "Befüllte Seiten", or "Ausgefüllte Seiten" or something completely different like "Seiten mit ausgefülltem Feld" (which is a little bit long for a table heading). What do you think is the best? Another question: As this is the support forum for the german language files, what are your opinions, about communicating in german here?

Uploaded another release 4.0.3

Just released an updated version. The translation now is "Modul wird automatisch installiert"