Leaderboard

Hello Ryan, hello everyone, I've just discovered ProcessWire and I'm delighted. :-) As a beginner with this CMS, I'd like to share one or two little thoughts that are important when discovering and evaluating this tool. 1/ I installed Softaculous for the first time, and the installer doesn't offer to integrate a site profile as with the latest version, which I downloaded and installed manually. It was by studying the documentation that I learned about the existence of profiles (and many other things) and the installation procedure and, if I hadn't spent time reading the tutorials, I'd never have understood the concept of profiles and templates which, incidentally, I still don't fully understand, but I'm working on it ;) All this to say that the beginner who installs with Softaculous has every chance of getting lost if he doesn't have the patience and motivation to read the docs first, which we never do when we test unknown CMSes in general. :-D By installing ProcessWire manually via FTP, it's already much better. Which brings me to point 2/ In the presentation of this CMS, it's repeated very often (too often) that it's simple, easy, within everyone's reach and, while it's true that someone with a bit of experience can manage it because the documentation and help systems are very well done, the lambda user who's used to CMS but isn't a developer will fear his own limitations. I myself am impressed by the quality and possibilities offered, but I feel very small when I read the various topics on these forums. How far would I go?) Having said that, I think this is a wonderful product and thank you all warmly for having invented it and maintaining it for everyone's happiness. :)

What you are seeing is a display glitch. The "Recently Found and Installed Modules" should be on a separate tab called "new", so it looks like you don't have any missing modules?! Not sure why the tab is visible in that case though.

Last shot: could it be because you don’t call the parent’s uninstall function? See ProcessHello’s exemple https://github.com/ryancramerdesign/ProcessHello/blob/189029f494870760107d8a621dfb5a59db53959c/ProcessHello.module.php#L227C69-L227C69

After a quick glance, I don't think so. Have you tried writing into the PW log from ___install and ___uninstall? This should at least tell you whether uninstall+install happen. In the later case, you should also see the page request that triggers the re-installation. Just to make sure: you have $config->debug enabled so you don't miss any warnings, right?

Or maybe it does? "get" does install and initialize the module, if available https://processwire.com/api/ref/modules/get/ Is it possible a visit occured right after you tried to uninstall?

Just install the module on another ProcessWire installation. If it's the same behaviour there the issue is in your module. If it's different, then the issue is in your current project. ?

Parts of it, at least, yes! I've had for a very long time on my todo list a related idea; basically something like the https://translate.wordpress.org/ portal for WordPress. Though I didn't honestly even consider using pre-built solutions. I don't say this lightly, but this is an area where WordPress is way ahead ProcessWire, in my opinion. Just a few reasons why I think their system is so good: It's a shared, easy to use, web-based, non-developer friendly system. Whether I'm a contributor or someone wanting to install a translation for a plugin, I don't need to figure out how author of plugin x wants to handle their translations, and I also don't need to know or figure out how to create a GitHub account, open pull requests, etc. This point alone is a major benefit and lowers the bar for contributing ? Just for the record, many plugins still bundle translations with the source code. So yes, both systems can co-exist. Anyone can contribute without core/theme/plugin author(s) having to do anything. I for one have access to Finnish translations for a few plugins. Permissions are handed down by general translation editors for the locale, which is much easier than having to contact individual plugin authors who may or may not be around and active, and may or may not be interested in bundling some language they have no personal interest in. Once a locale has enough coverage, it automatically becomes installable via the admin and via WP-CLI. Personally I use WP-CLI for managing site translations, as it makes things a lot easier to automate. Installing and updating translations is literally one command away, which — as someone who manages quite a few sites — is a big bonus. This, of course, only works for plugins that have been translated this way. Not all have. It's not a perfect world. Finally, the system handles versions properly. For an example if I wanted to submit a correction for the Finnish translations for ProcessWire version 3.0.184, there's no easy way to do that. Maintainer of the Finnish translations repository could set up separate branches or some other way to handle it, but this would be a case by case thing, and there's no guarantee that the language pack maintainer is interested in such a thing. In the past I've also contributed via Launchpad, which (at least back then) was essentially the same thing for free / open source software, and worked really well in my opinion. Anyway, I'm still interested in this idea, but have not had time to pursue it myself. Maybe one day, unless someone else solves it properly before me ? In my opinion it is a viable idea, but there are many questions to answer, and quite a few of those are not straightforward. Also I believe that in order to gain traction this would need to be somehow integrated into our current translation tool(s) and it shouldn't be too opinionated (for an example I personally would prefer it to not update anything completely automatically, as was suggested here earlier.)

I have created 4 larger wesites with drupal 7 before I got to know processwire. The modules and the community are great with drupal. But in the end I found it extremely annoying and frustrating. It was no fun and the projects often ended up taking much longer than expected. I can't say how it is with the newer versions ... If you want to have clean code the templating is quite complex. It seemed to me that the Drupal way was rather to take the very complex code as it is output (with nested elements and classes) and then just customize or hide elements in CSS. The module "views" (perhaps the most popular in drupal) is quite complicated and in the end limited in its possibilities. What is complicated to click together in "views" can often be done in processwire with pages->find in one line! What I also found annoying was that, depending on the modules used, the backend no longer looked very uniform. This is much better in processwire. If I have to make adjustments to the websites today, it takes me a while to think my way back into the structure and understand which module creates which content in which place. I am really happy to have found processwire and will certainly not be using drupal for another website.

@Simi Problem solved. PHP 7.4 ZIP extension option --enable-zip was removed. You need to manually install Zip and ZipLib in PHP. The rest of the access rights must also be set. But, I still do not understand why errors are not displayed in the log file? Make sure /site/assets/cache/ directory is writeable for PHP. Make sure your site modules directory (/site/modules/) is writeable for PHP. ZipArchive class is required and your PHP does not appear to have it.

I don't know the PageTable field, but ... there are settings which lets you decide what to do when a (language supported) field (or page?) is empty: don't show or inherit default. This is in PW since 2013 or version 2.4. If it is explicitly with a single field that should be excluded if blank (and there is no setting what to do on empty languages), but the rest of the page should be rendered, at least one can define that in the rendering template file: <pseudo-code> If language not is default AND field is empty: skip output </pseudo-code>

edit: well, that was easy $f = $fields->get("title"); $f->set("langBlankInherit", 1); $f->save(); I'll keep it here, in case someone else searches for the same thing... Is there an API function to change the language support blank behaviour? e.g. change the behaviour of dozens of multilang fields via API? (from "show default language" to "blank" or vice versa). I see in the DB-table "fields" an entry like this: "langBlankInherit":1 (field "data"), when set to remain blank... (Using dev version 2.3.2)