dragan

Easiest thing to do is to add some custom CSS to admin.css, e.g. body[class*="editor"] #notices { display: none; } that would hide all notifications for role "editor". Or some variation thereof, e.g. body[class*="editor"] #notices .NoticeDebug { display: none !important; } body[class*="editor"] #notices .NoticeMessage { display: none !important; } The cleanest way would be if this core module would have an in-built permission, then you could handle it normally via the PW access system.

Did you try to install the same mySQL version elsewhere (e.g. locally) and see how it goes? You could at least narrow down the issue (mySQL, or some DO-specific settings). Did you try access the DB directly?

You can try to fine-tune the DB https://dev.mysql.com/doc/refman/5.7/en/fulltext-stopwords.html And for advanced stuff, you can play around with fulltext searches (raw mySQL queries).

I would take a look how other module developers handled this. A good example is Tracy Debugger (or probably any other module that has lots of files/sub-directories), e.g. if($this->wire('input')->post->uninstallModule) { $dependents = $this->wire('modules')->getRequiresForUninstall($class); and then the relevant code in wire/code/Modules.php getRequiresForUninstall + public function ___delete($class)

Ah, centered! LOL, I knew I was missing something... I'd say, stick with your solution. With frontend only, you'd have to use JS as well. For at least big screens this might work though (updated): https://codepen.io/dragan1700/pen/bGNZBEK?editors=1100

Actually, the .gitignore in PW root is a nice starting point already. Some of the things I would probably add: *.notes *.sql *.zip site/assets/cache/* site/assets/ProCache* site/assets/pwpc/ site/assets/sessions/ wire/ .sql + .zip are most likely local backups, so I def. don't want them included site/assets/... stuff depends - cache (regular + ProCache) stuff + sessions I'd also not want to carry over. wire/ should certainly not be part of a repo. btw: .notes is just how I store login details; Apache blocks web-access to any files starting with a dot anyway, but you don't want to take chances, so I added this to .gitignore too.

Not sure, but I guess this applies to fieldsets as well: https://processwire.com/api/ref/inputfield/#pwapi-methods-collapsed-constants $field->collapsed = Inputfield::collapsedYes;

@Haagje R. I assume you have FTP-access? The error screenshot you posted says that your PW installation still has the install.php in root. That should have been removed right after the initial installation (removing that file - and others - is actually part of PW's installation routine). If that install.php still exists on the server, simply delete it, and try again. PS Checking https://www.neuro-insight.de/install.php throws an error about your 404 page not being viewable by guests (guest user = not logged in). So there might be more strange things to check...

here's a quick try: https://codepen.io/dragan1700/pen/bGNZBEK?editors=1100 Whatever you do: don't ever try to do stuff like "underline only the last line of a text block": it's a major cause of migraine. Without using JS this can't be done (yet) only with CSS alone. (Well - not unless you do PDFs, of course, or don't have to make stuff responsive...). A client recently came up with BS like that (which was designed by another agency), and we had a hard time explaining why this was not a good idea.

quick, dirty & ready ? $this->addHookAfter('Page::render', function ($event) { if ($this->page->template != 'admin') { // just an example I use in almost every PW site: add responsive wrappers around iFrames: if (strpos($event->return, 'videoWrapper') === false) { $event->return = str_replace("<iframe", "\n<div class='videoWrapper'><iframe", $event->return); $event->return = str_replace("</iframe>", "</iframe></div>", $event->return); } // another example I use in almost every PW site: add responsive wrappers around tables: if (strpos($event->return, 'scrollTable') === false) { $event->return = str_replace("<table", "\n<div class='scrollTable'><table", $event->return); $event->return = str_replace("</table>", "</table></div>", $event->return); } $cleaned = preg_replace('~(<h[23]\\b.*?>(?:<[a-z][^>]*>)*)(\w+)~ism', '$1<span>$2</span>', $event->return); // BitPoet's regex magic $event->return = preg_replace('/<p>\\s*?(<a .*?><img.*?><\\/a>|<img.*?>)?\\s*<\\/p>/s', '\1', $cleaned); // remove default paragraphs around images in CKE } });

Did you inspect the toolbar with the browser? You should at least narrow down the issue that way, i.e. if it's a CSS or JS issue. Or maybe you get 404 errors on the icons that are not displayed.

@Macrura I'll try and give some more information. Version: it seems SF installs actually two modules. One is v. 1.0.4, the other 1.0.3. Since I just installed it 1-2 days ago, it's unlikely I accidentally picked an old version. I'm using the JSON kitchen sink version. I de-installed SF y'day and installed again today. The same issues persist. I attached a few screenshots. before installing: after installation: after installation, under modules (notice versions 1.0.3 + 1.0.4) Trying to update process SF: editing the page under /admin: the page I entered for the JSON is 100% correct: Thanks a lot for looking into it.

I can't answer all of your questions right now, but you should never edit any file in the wire-folder. It will be overwritten the next time you upgrade PW. With admin themes, you can simply copy the entire admin-theme folder from wire/modules/AdminTheme/AdminThemeDefault to site/modules/AdminTheme/AdminThemeDefault. PW will notice there are two versions of the same module and ask you which one it should use. Just select the site/... version and then you can work with the copy. (I think that applies to any kind of module - not just admin themes) re: your first use-case / question There's an old module out there which does something similar: Pick an image from the page and display it in the page-tree. iirc it's a module (or hook?) by @Soma; search the forums - you'll find it eventually.

@Macrura First of all: Thanks for this great module. I noticed it already when you first released it, but because there was no real for it in my own projects, I never installed it till now. I found a confusing behavior (bug?) when I use the kitchen sink example. No matter what email address I try, PW always shows me an error: "InputfieldEmail: Please enter a valid e-mail address - Email Test" It doesn't matter if I use a real, existing email, or just a semantically correct one. What's even more strange is that this red error shows up on every page in the PW admin - literally everywhere. Am I missing something obvious? PW throwing an error if a required field is empty or doesn't match some regex rules is one thing, but that should only be visible in the respective page-edit screen, not globally? The only thing I noticed: There is no "autoload disabled" checkbox in module/edit?name=ProcessSettingsFactory I'm using SF 1.0.3 and ProcessWire: 3.0.149 PHP: 7.3.13 Webserver: Apache/2.4.35 (Win64) OpenSSL/1.1.1d MySQL: 5.7.24

You could try https://modules.processwire.com/modules/settings-factory/ Probably overkill if you only really need one single field, but really useful if the number of such global fields increase over time...

Well, maybe "breakpoint" is not the right word, i.e. the code won't stop to process like in JS dev tools. But you can dump all kinds of stuff with d($doc) inside the template. Then you'll quickly see e.g. if a var doesn't contain what you thought it should etc. (null, 0 results, nullpage etc.). I'm sure you used it a million ways... What's perhaps a bit misleading in Tracy, is that addBreakpoint() is meant to only be used with the performance panel. So yeah, not exactly the same as adding JS breakpoints in frontend-land ?

I have of course read that thread, but that approach has a few limitations. If you set up categories and sub-categories the way you did, it works without a doubt. However, if you want to stick to the DRY principle (don't repeat yourself), and choose a maincat<-->subcat relationship that I have chosen, this won't work. In a real-life scenario you'll likely have several sub-categories that are eligible for more than just one main category. Suppose you (or your client) re-names a certain sub-category, you'll have to update all instances of that one single sub-category for each main-category as well. With a small setup this might not be an issue at all. But as the site (and products...) grows, this can turn into a chore to maintain. I'd rather have a separate, independent set of sub-cats to choose from. IRL many of those sub-cats are overlapping ("backups" or "upgrade" surely isn't only available on Win or Mac). From a UX/GUI perspective, when you need multiple subcats to attach to a maincat, your options are rather poor. Select Multiple, even in 2020, looks and feels... like 1999 (without the party aspect). So if you decide to use checkboxes in the admin, this approach won't work.

Is your file-field configured to have just one file, or multiple? If multiple, you'd have to do $filefield->first()->url Since you get 403 (forbidden) errors, it's maybe more likely those file-fields are somehow access-protected. Check your access setting of that field and/or template. Do you get these errors also as a logged-in superuser or just as guest? Do yourself a favor and install Tracy Debugger (if you haven't already). You can then insert breakpoints in your code (similar to console.log() with Javascript), and you'll see more infos and hints about the error(s).

I have no idea. I just tried it here as well - RM fields get ignored. Ryan stated a while back (~ 5 yrs ago) that the whole concept of this field-type was outdated, and wasn't delivering the performance advantages etc. he initially had in mind. That's also the reason it eventually got kicked out the core. I guess this field-type is much older than some newer field-types like repeater matrix, so it never got updated to accomodate them. It's not too hard though to re-build the same basic functionality though with a regular text field and a hook that on page-save collects all text-based fields in your template(s) and saves it to that field. What you could also try is using fieldtype(s) instead of fields: https://processwire.com/blog/posts/processwire-3.0.91-core-updates/ This won't help with caching though, just keep your selector string a bit more readable...

Maybe one of these forum threads / issue reports will help you find the culprit: https://processwire.com/talk/topic/17132-image-doesnt-save/ https://processwire.com/talk/topic/13724-problems-uploading-images/ https://github.com/ryancramerdesign/ProcessWire/issues/1174

I just installed the module (though it's still at version 4, according to module info) and after trying to run it, I just get: The process returned no content. ProcessWire: 3.0.148 PHP: 7.3.13 Webserver: Apache/2.4.35 (Win64) OpenSSL/1.1.1b (Laragon) MySQL: 5.7.24 Could this be a Windows issue? Do I have to enable special PHP extensions first? Nothing in Apache or PHP error logs. The strangest thing is: The page title says "Form Builder". (?) OK, after unpublishing the Form Builder page, I get a static version alright. I was a bit puzzled though that each parent page is actually a folder in the static version. Going to play around a bit more. Thanks for sharing this module!

Here's an example that works without having to first save & re-load the page you're editing. The setup: In my page tree somewhere (usually under a parent I call "meta", "settings" or similar), I have main and sub-categories as pages: The sub category pages have template "empty" with just the title field and nothing else - not even a physical template.php file. The main category pages have tpl "maincat", which holds an addtl. field "main2sub", which is a page reference field. Here you map your sub-categories to each main category. My (simplified) product tpl has two fields: maincat -> page reference field single. Parent = main cat / 1366 select_categories -> page reference field multiple / output as checkboxes. No configuration set in field settings "selectable pages". So far, so boring. I need JS + PHP for the auto-switch to happen. I created site/templates/admin/admin.js In order for PW to even load it, I edited site/templates/admin.php: $config->scripts->add($config->urls->templates . "admin/admin.js"); require($config->paths->adminTemplates . 'controller.php'); // this must stay as the last line admin.js looks like this: It's written in plain JS (ES6). With jQuery it would have been a bit shorter, no doubt, but I got into the habit of using as much vanilla JS as possible. If you need to support older browsers, you'd need to run it through something like Babel. In nearly every PW installation, I create a dedicated template + page that acts as an API / AJAX endpoint. Create a new template "api", enable URL-segments, create a file "api.php" in site/templates/, and finally create a hidden page somewhere that uses this template. Use the option "must have trailing slashes" (check yes). The api.php looks something like this: Basically, what happens, is: On page load and on main-category-dropdown change, I send an AJAX request to my API script with the page ID I'm currently editing and the main category page id. The API script then sends back the matching sub-categories as JSON. JS again then loops through all checkboxes, and de-activates and hides all non-matching choices. It works, but it's not perfect*. I wish PW had an in-built way to handle such scenarios. As always, YMMV. * There's a split second on page load where you see all sub-categories. And also, when you select again the same main-category (without having saved the page), if you made selections previously, they're being erased. The first (minor) issue could probably easy be prevented if you set your subcat field to closed. You could first do your JS-syncing and at the end make them visible with Inputfields.open. Speaking of Inputfields JS API... I found that Inputfields.reload() didn't work here in my example (I tried several types of fields). Pity - would have made such a thing much easier...

@MilenKo Finally managed to put together a quick setup. Good news is that it works (with a hook), but it's not ideal UX-wise. In order for the sub-categories to switch, the page must be saved first. Only then do you see the valid options. Perhaps this can be optimized with the new JS field API, but I haven't tried it yet. On the other hand - if the number of main and sub-categories won't change constantly, you could simply create four sets of page-reference fields (one for each main category), and work with field dependencies (show only if ___). But that won't scale, and if your above example is just a simplified example, you'll get into maintenance hell sooner or later.

Check your mySQL collation / encoding type maybe. Is it anything else than utf8? I always choose utf8_general_ci.

I'm not sure I understand the scenario fully, but I think you could easily achieve this with core PW functionality. I don't have time right now to build a "quick and dirty" example setup, but I guess with field dependencies and page fields (as the main "tools") you should be good to go. Maybe I'll write a quick "proof of concept" later...