LostKobrakai

It was quite a bit longer. I've had people post about it on twitter since yesterday evening my time (like ~16h ago). But I'm not aware that processwire.com or the forum would be served through cloudflare and couldn't find any hints in request header as well so I doubt this is the problem.

I'm not sure if field or template level is really what you're after and not rather "site wide" level. If you need settings, which apply to your whole site you can always create a single page, which holds all the setting for the your site. You could even make a custom api variable with it in e.g. `init.php`: $this->wire('settings', $pages->get("parent=1, template=settings")); If you don't need the settings to be editable via the admin interface you can also attach your own properties to $config.

Which is better doing what exactly? Without context there's no way to really answer that question. Both bring types to javascript, but that's basically where the similarities end.

$page->images->slice(0, 5)->implode(function($image) { return "<li><img src='$image->url' alt='$image->description'></li>"; }, array('prepend' => '<ul>', 'append' => '</ul>')); This would be the processwire api equivalent. From looking at the perch example I'm wondering if they use it for creating templates based on the markup. Otherwise I'm not sure why a lable would be given here.

I mean the cmd in windows by now is missing a lot of basic stuff ?

@buster808 Can you please use the code blocks provided by the forum instead of copy pasting directly from your editor into the post. It's really hard to read the way they're right now.

The export/import feature of pages does only transfer pages not fields. There's a similar feature for fields though.

To me site profiles are startpoints. I see it as bundle of dummy/base content + the necessary modules for letting the site work in its installed form. For keeping the profile itself up to date for future installs I‘d probably use git submodules, but distribute it as plain zip with everything in it (iirc github does that for the zip download). When things in a site should be managed after the initial installation as well I think it should be done by a module (can be installed by the profile as well). The module can handle all the necessary changes to content on update and has ways to setup dependencies to other modules. Sadly we‘re currently in a weird middle state of having kinda integrated composer, but also really just using is as a parallel universe, which means you either use composers dependency resolution or processwire‘s, which to me means skipping conposer is currently the better way if broad adoption is the goal.

I'd much rather have this in the modules directory, but it still has potential: maybe some config, an option to add custom domains, fresh/stale status detection or a manual way to trigger list retrieval (also retrieve it on install). I mostly wanted to get the basics across and show that often times it's not too hard to implement stuff on your own. This became a 100 line file with maybe ~30 lines of actual business logic. I'd be happy if someone else would pick it up from here and properly support it as a module in the directory. I simply don't want to add more to the few stale modules I already have with no longer doing much work in processwire.

I just wrote that before posting it here. It didn‘t exist a few hours ago ?

I'm not really sure, why this would need to be bundled with FormBuilder. The attached module is a totally self contained module, which downloads the list from the given github url. It automatically tries to update once a day and uses the etag/if-none-match headers to determine if the list itself changed, to prevent sending of the list if there wasn't a change. The list and the etag are stored using WireCache in the db. There's public api to fetch the list and check if a domain is in the list. To use it in FormBuilder hooks should be the answer. EmailSchreck.module

Just like you‘ve used gif/png/jpeg when appropriate in the past you‘ll likely use different upcoming formats in the future. It‘s unlikely we‘ll get a single general format anytime, which would trump more specialized formats across the board. Also the performance is actually less of an factor besides the bigger hurdle of widespread support. I‘ve at least seen a handful of demos, which trump webp, but those formats seem to never have made it past the initial research/implementation phase.

Yeah. Communication is certainly the most important part. Depending on how you service your clients I this might even be entirely out of line. The second step would be having a proper licensing and contracts between yourself and the customers. This is the only thing, which will help you if there's someone not playing by the rules. Only after that you can look into making it harder to not play by the rules e.g. using license keys or tools with can encode php code like ioncube. Stuff like that can easily backfire though. For me code using ioncube would be a big reason to look for alternatives. Code which talks to your servers (e.g. license code validation) or even more invasive things like analytic tracking can cause problems in tightly locked down server environments, where code is not allowed to connect to arbitrary external services. So it might also depend on your potential customers what of the methods makes sense.

Imho the much more compelling reasoning against using jQuery is going up the abstraction ladder and using some library, which handles e.g. DOM manipulation for you and not going down the ladder to do everything in vanilla js. jQuery for one part is a great library if you really want to manually handle changing the DOM, but I much rather deal with templates and data then with the low level "making the DOM behave". What I never really liked is how ajax was bundled with jquery, as it really has nothing to do with the DOM at all. At the time it might have been about "we make things simply work cross-browser", but it could've been packaged more separately.

https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/ProcessWire.php#L182-L217 This will point you to anything happening at startup. Most of the important stuff is part of ProcessWire::load, which triggers the initialization of most common api variables. That's exactly what is happening. On each request ProcessWire does load all fields/templates into memory from the db.

I'm not really sure why we would actually need a new permission here at all. We already have a permission to view a page and one to edit a page. It's just that ProcessWire is build with custom frontends in mind and "viewing" a page is generally considered to be done by viewing the page on the frontend. That's why we have ProcessPageEdit and not ProcessPage. I can see that repurposing ProcessPageEdit one could make it basically behave as though any field would be set to "not editable" when a user only has permission to view a page, but not edit it. I just expect that the implicit notion of "you look at a page on the frontend" is build into many places. Like everywhere you currently have a link to edit a page the permission checks need to be changed, it probably cannot be named "edit" anymore or at least must dynamically be switched between "edit" and "show". The latter might still cause some confusion.

It's pricy sure, but I don't think it's more pricy than other mac hardware given what you actually get. If you really need that kind of hardware it'll cost you a few thousand bucks elsewhere as well.

Can you please share why this should be part of the core in your opinion? To which problem(s) processwire users have would this be the solution?

The functions api is not multi instance aware anyways, so you cannot use it in `site2` anyways. If you disable it via the config the error should go away.

Just a small amendment to the above: If you really want a single dashboard I‘d rather look into another processwire install using multi instance support to load the others for data access. This works for things on a single server.

I'm not yet fully sold on Flutter. I like the idea behind it and it's certainly appealing for cross platform mobile dev, but it also feels super verbose and you still probably need to handle two versions of your app if you really want to adhere to the UI/UX patterns of the different platforms. Having one codebase is certainly making it easier, but it imho doesn't remove the issue. This is even more apparent if you look at the differences of desktop apps. Also with its focus on UI development I'm not really sure where I should put it when it comes to non-UI tasks, which are as important if you need to do anything without being connected to some server elsewhere. Given I'm working with elixir for most of my time OOP additionally becomes less and less appealing ?

Fieldsets are only logical groups, but they don't change how data is stored/retrieved. Each field in a fieldset still is a direct child of the page and any nesting is only presentational. If you want nesting we have https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/#fieldset-page-fieldtypefieldsetpage. This is real nesting with another page behind the scenes, which does also allow things like reusing a field in the "fieldset" as well as in the parent page.

The number of fields/templates should only become a problem for like 100+ numbers. 26 and 16 is certainly not in that realm.

On the reasons why floats are bad for money values: https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency https://mathjs.org/docs/datatypes/numbers.html#roundoff-errors Math.js seems to support something called "BigNumber" to do arbitrary precition math, which should always be use for monetary calculations. But math.js does seem to also detect issues in floating point math and give you a rounded value, so maybe it's fine without that for simple calculations, where automatic rounding doesn't result in errors in the result.

You're creating an infinite loop. You hook into "after save" change something and save again, which again triggers your "after save" hook and so on. Either look for another hook to do your work (potentially change things last minute before the actual save) or add some way for your hook to only run once and not for the saves it initiated on it's own.