LostKobrakai

One is a single select input and the other one is a multi select input in the tagging style. You can see those here: https://harvesthq.github.io/chosen/ (first two examples)

Otherwise the .htaccess (or php not sure) will do a redirect, which essentially strips all the headers sent with the request.

I'm not sure if it works correctly, but by a quick glance in the code FieldtypeSelectExtOptions should let you choose InputfieldChosenSelect if installed.

I'd like to contradict. The admin themes we have really need a css overhaul and cleanup (and maybe docs), but a prebuild framework is in my opinion not the way to go. Because it's not developed internally every special usecases the admin does have will feel like a hack to the framework. Framework + custom workarounds will always be bigger (more code / more maintainence) than a customized solution. It's also a matter of branding. True, one can add custom colors to UIKit, but in the end it's probably still noticable enough that it's UIKit. Also consider all the markup in core and 3rd party modules, which are needed to be supported the the admin theme. I doubt any prebuild framework is bendable enough to support that level of custom markup coming from our side.

Where did you pick up that information?

It's still a beta release and I'm not sure why they should worry about a sass version as it's ever been a less project and it's not yet a stable release. But the marketing strategy of replacing the whole website at this stage truely is strange.

Choosing from a predefined list still has the issue, that the data-attribute is saved as markup in the db and isn't dynamically generated/updateable.

I don't think ProcessPageEditLink is the correct way to enable users to create such markup, especially the group syntax. Personally I wouldn't even use CKEditor for that. Just imagine the syntax does change a bit in a newer version. You'd need to edit all the textfields using that markup. If you really need to use CKEditor I'd rather go for a class or something and use a textformatter to generate the necessary data attributes based on that class(es).

Oh, I always though there where no pages under that url in the page-tree (which is the only time urlSegements are viable). If there are, than Robin's answer is the way to go.

It was a 3rd party module even before the upgrade and there's no decent alternative / updated version of the plugin, which would be compatible with the new forum's version.

I don't think vuejs is needed to test the problem here at all. The thing needed to work is urlSegments for the homepage, so that arbitrary url (besides the /api endpoint) still just return the homepage's content. Normally this should be working if there is just the homepage and an /api page, when urlSegments are enabled for the home template.

Properties are also useful for the places, where one might use the result in any getMarkup() calls (e.g. what to show in the page list). $pageArray->explode('<a href="{editUrl}" target="_blank">{lastModifiedStr}</a>');

May I ask, why you're not using processwire's buildin translation capabilities? Regarding the mysql queries. You're correct that you'd get 60 mysql queries, but that's really nothing to worry about if you're not experiencing performance issues. If you would there are various ways to improve uppon that like autojoining fields or one of the many caching solutions of processwire.

@Martijn Geerts So that's a kinda fire and forget approach? There's no way to retrieve any of the output of that curl request. @FrancisChung I had great joy exploring a bit about what's possible with elixir. It's a great language for concurrent programming and not as hard to grasp as erlang even though it runs on the same runtime.

Could you maybe supply a example about what you're trying to solve? You explanation above is unfortunately a big nebulous. And just to ask do you see any performance issues with your current implementation?

ProcessWire doesn't care a lot about what files are in those folders (try removing a file uploaded via the backend). It only really cares about what data is stored in the db for the file field – otherwise it couldn't distinguish multiple file fields per page. If you have big files you won't want to upload via the backend you can upload a small fake file instead (same name as the big one) and afterwards replace the file via ftp.

Did you try to downgrade again (replace index.php/wire folder)? This might resolve your issue until you can figure out what's breaking on the upgrade. Also there're not really reasons to upgrade except you want to change anything on your pages, which is not like your second post sounded like.

The FileCompiler does not automatically iterate over any folders or files. It does only compile files directly included by processwire (modules/templates and so on) and any files included in any of those files.

// show pagetable field only if there are items in it $pages->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { $wrapper = $event->return; if (!$wrapper->has('NAMEOFYOURPAGETABLEFIELD')) return; if ($event->object->getPage()->NAMEOFYOURPAGETABLEFIELD->count) return; $wrapper->NAMEOFYOURPAGETABLEFIELD->collapsed = Inputfield::collapsedHidden; }); This is more reliable as it does also work if page table entries are not stored as children or if there are other children for the page besides the pagetable ones.

Afaik the most mature tool for async php is reactphp. But really async code is not a peace of cake and there are probably better languages out there than php to execute code concurrently.

How about letting a dedicated AdminActions.module handle all the serious work (e.g. like WireActions), so actions are also triggerable via the api? I can imagine that some actions might be useful to be run as part of a migration (shameless plug :D) and not just via the backend.

Field import/export is even in recent processwire versions declared a beta/experimental feature to be used with care. So while this might sound harsh your issue is not more of an security issue than any other one a developer might introduce by uncareful actions. Especially the more complex fields like repeaters / pagetables are prone to miss-matches for some of the plain id values they're using, which is probably the no1 reason, why the feature never made it into stable form by now. The things to consider on processwire's side would be to make the import process customizable by fieldtype so that the repeater fieldtype can force an update of the parent_id on import. This can only work for repeaters, as the parent pages are not user changeable. The other thing to consider would be to make the pagefiles directory be lazily created, so that pages without actual files do not create directories. This wouldn't have prevented your infinite loops, but at least the part of filling up all your disk space.

Inputfield dependency selectors work by parsing the values of the html <input>'s and alike. If a field is not editable these are rendered at all. If you need visibility selectors to work with fields hidden/not editable use a hook after ProcessPageEdit::buildForm instead.

If you're using mod_security I'd suggest looking into disabling it. There are various topics here in the forums, where mod_security was causing all kinds of troubles when running processwire.

I know that blog post, but having had so many issues with it on 2.7.3 I know for sure it doesn't work at least in that version.