LostKobrakai

It's probabably more like: $pages->get("template=your-template, n1<=$myNumber, n2>=$myNumber")

I've two points. Does the math lib calculate using decimal math? If not is probably should, if not you should at least remove the parseFloat in your javascript. parseFloat("0.100000000000000005") // 0.1

You can look in the dev tools network tab to see the actual result of the ajax call and the error, which is returned. Afaik ajax upload is only supported for pages though, as the page is a piece of data, where the file can be appended to (with a temp. flag). Everywhere else there's nothing you could append the file to for later processing.

Using %= means your value will be escaped and wrapped in "%$value%". Using that with LIKE in sql means you'll get all results returned for an empty string value. Both – returning an empty or a full resultset – can be valid expected results for a filtering operation so it's best to align with the default sql behavior and not adding special cases, which is at least the less surprising option. If you don't want to allow searches for empty string is ultimately a business decision you have to take care for on your own. If that's a concern I'm wondering if you don't set limit on your query. Limit (and in extension pagination) makes the problem of an empty string not filtering the results a non-issue.

If this is a managed hosting and even a fresh .htaccess doesn't work contact the hoster to fix the issue. If it's not managed locate the logs for the apache server and see what it tells you.

For any kind of non-php based storage (a.k.a. any long lived one) you need to serialize the data somehow. The simplest and most dangerous is php's serialize, json is an option or implementing a custom fieldtype, which is probably the most work depending on what you're actually storing in the wirearray. Afaik it handles PageArrays by only storing the page ids and recreating the PageArray on load.

It even surprised myself when I had a look a few days ago ?

showIf/requiredIf are computed in javascript directly based on inputfield values and conditions on datetime values are not supported. The inputfields only hold text values, which is only converted by the server to an actual timestamp.

There's also Module::upgrade https://processwire.com/api/ref/module/ which is what the core and may existing modules are using. Pw already keeps track of versions for modules, so you mostly need to find a good way to manage what should actually happen when the version changes.

There are a few solutions and the core in the end even added an selector for the usecase.

There‘s the $classLoader class in the core if you need to setup autoloading.

That's really nice. I like that it works on the whole monitor instead like lot's of other tools only locally. I'd just really like a permanent mode, where I can work while having the filter applied.

Online Editors/IDE's look great from the outside, but personally I'd rather be in control of my environment. E.g. I had to disable tests in one project for my CD pipeline (and run tests on gitlab instead) for about a year because the platform only supported hardcoded databases, but I needed to run postgres with the (rather popular) postgis extension. They since switched to allow for custom docker containers as additional services, but it show's how limiting platforms can be. At least for me it's hardly just about having a fancy text editor on the web, but there are quite a few more components to a usable dev environment.

There's also the question if the topic creator meant pagination in the backend or for the frontend.

For mac apps I can also recommend https://paw.cloud/.

I've not used it much and I don't really like the api much (seems very verbose compare to other tools), but it's integration makes up for very much. It's possible the best testing tool I've seen to date in terms of visualizing what's happening but also having an interface to visualize what's happening as the testsuite is run.

Personally I'd look into making rdp work and maybe even just tunnel it over ssh and not even caring about securing the rdp service (port opening and stuff like that). I really like rdp for it's "virtual desktop" approach, which is way more sane than sending basically a video of the server side monitor. X11-forwarding afaik works similar, but I'd rather try to emulate rdp on the linux system then X11 on windows (or potentially other clients) ?

https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Modules.php#L55-L85 The flags are binary flags with their values being defined in the core files. To uninstall remove the flag for 1 or 2. There's not really something to be documented, as the database is not meant to be directly interfaced anyways. Documentation means people rely on the information and therefore changes can no longer be easily made.

You could try using a PHP hannacode with: ?> <html>test</html> <?php

Gitea is great. I had gogs (which gitea forked) running on a server of mine for a while, but gitea is more active and open. But I must also say I only use it locally to move repos from my laptop to the desktop for all the WIP stuff, which doesn't need to be in some cloud already.

I really like the side by side layout for content and nav. I imagine it being a great solution to cut unnecessary cost in catering to smaller screens and larger screens with different layouts.

My question was less about the field definitions, but more about the data stored in a field defined by your module. E.g. say I want to change an integer field to a float field.

Can you share a bit more details on how data is handled. E.g. what happens if I change a field or even remove it.

For me it was a platform switch away from ProcessWire and even PHP. It had nothing to do with DynamicRoles at all. Without the issues mentioned/open prs on GitHub it should work fine. I've even looked into making it even more flexible once, but never finished the work.

I'm also no longer using DynamicRoles in a production env. It was working well though with the fixes I proposed in the repo and on pw 2.7.3. An addition to @szabesz comments above: The thing to keep in mind with $page->viewable() as the "Solution for Access-Control" is that it's easy for it to not be enough. As soon as pagination is needed one needs access control at the database layer or pages will have different numbers of elements (even down to none at all).