LostKobrakai

I think forgetting settings by default is the most clean way (on uninstall), but there should probably be ways to let developers choose different paths if needed. Maybe "deactivate" could be a non destructive way to disable a module, whereas "deinstall" is the clean sweep, where everything is removed.

Which folders/files will be created by the application after installed ? After installation usually the only place where folders/files are created by ProcessWire is inside /site/assets. But 3rd party modules may also use different places. Which folders/files usually be overwritten? Same answer as above Which folders/files using as cache, as session, as temporary? /site/assets/files /site/assets/cache /site/assets/sessions Do ProcessWire supports logs? If so, where is it? /site/assets/logs, $log Which files are using as configuration files? Should I concern about template configuration files? That's the place where deployment tools won't help, as ProcessWire doesn't store configuration in files (for the most part anyways). There are a few tools out there to accomodate for that fact, but iirc my Migrations module is the only one you could run via cli by a deployment script.

Just keep in mind that this will be another mysql query, whereas the other call is made in php runtime. It won't load the page's another time (as they are already loaded), but the selector does still need to query the db to know which pages to return.

That's because of the differences between the database querying $pages->find() and the runtime only $somePageArray->find(). The first one does parse status keys and date strings and alike, whereas the latter does not do such conveniencies.

It does with 3.0. Only 2.8 is currently not available due to the temp situation of having it as extra repository on github.

I'm always amazed by the interfaces you implement in the pw admin @renobird. It's crazy.

That's why it's called page table. It's not meant to be a layout builder of sorts. The ProField matrix would probably fit your needs better.

urlSegments are what you're looking for.

As the module config is stored as json string anyways you could use any array structure to model those config data, but there's no ready made inputfield to support that structure by now. All multi instance/multi value fields do depend on actual pages be present (or at least a fieldtype db table for fieldtypetable).

Only template files and modules are compiled. Files bootstrapping processwire won't trigger any compilation.

Both functions can be used to alter the markup. Only difference is that format() does not receive $page and $field.

The index/htaccess version state the version of processwire that did introduce the latest change to the file. They are probably not compared to the actual pw version you update to but just if the version changed between htaccess_old and htaccess_new. The numbers in the files are simply manually adjusted by Ryan.

The module does not use a difftool but only compares by version/indexVersion in the first few lines of htaccess / index.php

Tracy Debugger has a console panel, where you can run one-time code to be executed.

Looks like photoswipe, but is a bit more heavy on features: https://sachinchoolur.github.io/lightgallery.js/

This one does also use a quite simple custom table. http://modules.processwire.com/modules/migrations/

It's even longer https://processwire.com/blog/posts/processwire-core-updates-2.5.24/#field-dependencies-upgrades

@Macrura that's outdated info. I've implemented the pipe OR switches probably about a year ago. Only the OR groups are not supported in that regard. The issue here is that support for inputfield dependencies in repeater/matrix fields is still kinda experimantal. It can work, but often it doesn't.

link_type|link_intern_content=1

If you wrap your own ajax handling around the markup the module does supply, yes. But there's no out of the box ajax.

Can you include / open those files with the php runtime (e.g. php -a or a custom file)?

Disabling csrf, while apparently making it work for you, will also make your site vulnerable to csrf attacks, therefore it's not recommended to do that.

Infinite scroll would be ok with automatically updated history state and a max number of images in the dom (aka removing / re-adding older ones). But this essentially renders the scrollbar useless.

You need to specifically enable the field to use a datepicker in it's settings.

There's already a nginx topic somewhere here in the forums (I think in tutorials) with a possibly more elaborate nginx conf. Maybe you could take a look at this one.