LostKobrakai

AdminOnSteroids is nice and it's features should be evaluated for the new admin theme, but I'm not sure there's even remotely the need to implement them in the core like you're describing things. The core should not strive for feature completeness, but rather in the direction of the simplest possible subset of features needed by most of our users. Everything else is a matter for optional (core or 3rd party) modules. Talking about your example I'd imagine that hiding description/notes is rather a anti-pattern for most use-cases as they're usually filled with information the editors/moderators of a site tend to forget but are important none the less.

Hopefully their own content and not simply taken from others

If you can reach your server at it's certainly not what I'm talking about. Also there are only a few rules in .htaccess, which you should consider when debugging issues with pages not reachable. Everything else in there is either not to be touched or only for specific features like for example https redirects or www. redirects. The 95% trouble maker in the .htaccess is the RewriteBase, because it's different depending on the actual apache setup on the server and if you're using subdirectories or not. Could you be more specific? Those 3 issues would be caused by different issues in your setup.

Apache and Nginx are both individual webservers, but only apache is supported officially by processwire. EC2 is from a plain server pov not different to other virtual server providers, but aws does have a lot of privacy / access rulings around all it's services, which is (or at least can be) super complicated for simple setups. That's why I think one should only use aws if one does need aws. I'm not sure how much knowledge you have about setting up your own servers, but if you're not quite comfortable with it I'd suggest you not doing it for any production work. If a simple shared hosting would be enough I'd charge the client a good amount extra for the hoops of setting up a virtual server in the first place. It's not only the time spent, but also the responsibility coming with setting up anything on your own. If you still want to roll with it I'd suggest you the tutorials over at digital ocean (initial setup / lamp setup) and using ubuntu. Ubuntu is the most used system out there and the digital ocean tutorials are quite well written and not really dedicated to their service per se. And just a suggestion about your "cloud loving" client. You might take a look a PaaS like heroku, which is as cloudy (in terms of scalablity/on-demand hosting) as aws, but a lot simpler to setup.

I'd imagine ProcessWire should run on any Linux derivate available to EC2, but may I ask, why you want specifically EC2? DigitalOcean or Linode do charge similarly and are way easier to setup than aws (with all it's enterpricy setup tools and permission hierarchies and stuff). I always feel people preemtively reach for EC2 even though they don't need all the things which make aws great over other services in the first place.

Without any rude intentions: If you can't get ProcessWire to run without docker on EC2 you shouldn't try to add docker to the game as well. It's only going to get more complicated and error prone.

How about hooking InputfieldPageTableAjax::checkAjax (and/or probably InputfieldPageTable::renderTable) and skipping all that hackish jquery?

You can certainly do it using page tables or the profield matrix, but often people don't like the UX of those fields to much for this use case. But it's the best we've got for that kind of content – and seeing that silverstripe UI I think it's not so much a problem for you.

If you don't do custom cropping (art direction) for your image-sizes you don't need the picture element. Using srcset/sizes is enough. Also you might want to look up the correct usage of nth-child as it's nothing you add in html, it's css. Syntax like yours does not exist in html (even if some js frameworks try otherwise).

<?php $entry = $page->homepage_media->getRandom(); echo $entry->video_strip_1->url; echo $entry->video_strip_2->url; echo $entry->video_strip_3->url; echo $entry->video_strip_4->url; echo $entry->video_strip_5->url;

I'm not sure you can get away with a one-size-fits-all solution. Data of fields just is different and therefore in different shapes.

$f = $page->{$field->name}; $title = $f->title;

Probably. I mean we do already have WireDatetime, which should be able to handle those cases and the $format in the sanitizer seems like ryan wanted to use it.

Did you do a modules>refresh?

Ok, I'm not sure why, but it seems like the format is not used in Sanitizer::date, which defeats the purpose of the WireDateTime class which is supposed to be more intelligent than strtotime.

From the php docs: If you really want to be sure about date parsing you'd need to specify the format otherwise you'll always find issues.

We already have a syntax for that operation: or-groups. But it's not supported by the parsing engine for inputfield dependencies (as well as runtime queries like $pageArray->find() actually). It's also not really an often requested feature.

Oh, only the files are on the NAS. Then I'd imagine this slow-down is to be expected. Network drives are slow (and XAMPP not the fastest to begin with). Network drives can be quite fast transfering single bigger files, but for lots of small files like a php project it's bad.

Pages::getById() is your friend.

ProcessWire selectors do not support that kind of operation. But as always you could use raw mysql via $database.

Do you use XAMPP on the NAS as well or a serious webserver? There are multiple topics on the forums of XAMPP or generally locally hosted sites being slow, some of them were resolved by using 127.0.0.1 instead of localhost for the db. Maybe take a look at them.

Inputfield dependencies do only support piped OR selectors like so: field|field2=value or field=value|value2.

This might be a bit off topic, but this problem has come up a few times. Maybe the modules directory could proxy downloads of modules and add the vendor folder on demand (to the module itself) if a composer.json is present. So users can choose if they do a composer install some/module or install it via the backend – without the benefits of a global dependency management tool in the latter case.

Probably only through menu builder. Nobody else knows how your menu structure does look like.

For some websites this might even be the goal. But I can understand your reasoning. It might be interesting to be able to use the module to create endpoints with a somewhat fixed queries. Once the experimental phase is over and it goes towards production queries could be moved from the frontend to the backend.