LostKobrakai

It depends. I'm mostly using templates and tree/branch relationships between pages to select (other) pages. Paths are also good if you're really sure they stay consistent. I'm using ids really only if I have to (e.g. alternative user parent). In the end not using ids is also more descriptive – it's like it's with magic numbers in programming. And it's a lot more resilient. If someone does accidentally delete a page the id is gone, whereas any other selector will just work as soon as you recreate that page. Edit: And the point, which is more in context to the topic. As soon as production and local development are running in parallel you can either not rely on ids or you have to (probably manually) edit every new id reference in your code on deployments, which has the not so nice side-effect of bringing your codebase out of sync.

In the ideal case you're not keeping log, but rather you make the local changes only via migration files in the first place. The actual number of those does not really matter as long as it's in logical steps. It might seem like a lot of extra work, but it really is – after creating a few of those – more a case of copy&pasting and adjusting a few key points. And the time saved when actually deploying changes is a lot. It makes the whole update process a lot more transparent and less error prone. I'd strongly suggest you to not hardcode/rely on any page IDs in your app (besides maybe ID 1 and 2). They'll get out of sync faster then you can keep track of it. The idea of separating tables might seems like a nice solution, but it would probably need a lot lot of core hacking to make that happen. Also it's not just the 'pages' table, but you'd need to split any field's table as well. It might work somehow, but I imagine it to be not worth the hassle and the inflexibility. I'm not really recommending anythings. Migrations work great for me, but every use-case is different.

I've just gone ahead and added such a repo to GitHub: https://github.com/LostKobrakai/MigrationSnippets. Maybe this can also serve as a resource for people, who are not sure they understand what this module does provide. I've already added 2 example cases. I think over time I'll add some more, but everyone is welcome to add their files as well.

My module does not really do anything on it's own. It's more a managing helper for handling/running those migration files. Any actual changes you'd write on your own using the processwire api (in those files). It's like you would have done these changes in the backend, but it's done by code. There are some helpers included to reduce the amount of verbose code, but that's about it. With the processwire api at hand you'll probably not even need to think about the db, which is probably the biggest difference between something like phinx or other frameworks' migration files to the ones my module does handle. You'll not manually add any new tables or columns. You'll just add a field to a template or create a new page or something. If you've handled all local changes using those migration files you can just put those on the production server and run them there as well. If everything went well all your changes should be applied as they were locally. Just keep in mind the module is not making any backups of sorts. This is the users responsibility. Your points about db dumps are certainly valid, but it just is the case, that almost everything in pw is a page, even users. There's no point in working against this. E.g. how should pw know which users where created by you locally and which one online in the production system? Same for normal pages. How should pw devide between a list of countries you added as pages for a select field and some other pages, which represent dummy user content you work with locally, but are not to be migrated. Especially in a dynamic structure like the pagetree where things can be moved around super easily and templates can also be changed as fast there's no point in even trying to separate out anything.

Man Google is such a nice service provider. I cannot imagine how many google maps implementations they broke just by applying policy changes "as of now". I mean I didn't like instagrams move to only "approved apps", but at least they told people about is half a year beforehand.

If you're using flexbox for plain alignment issues, where things just don't look as nice and tidy on old browsers there's no need to care about a polyfill. For creating grids and such things flexbox isn't really designed for and I'd simply stay with the good old float or inline-block tools. Css grids, which are really created to solve the grid issues, are sadly still way from being supported widely.

For this to work in a single selector you'd need a db connection from the repeater page to the holder, but you've only the field on the repeater "holder", which is the wrong direction. With an pagefield or a real parent/child relation you could use subselectors: parent.id=[myParentsField=MustBe, this=or|that], INeed=toBeThis, and=that You could only go this way: $holders = $pages->find("myParentsField=MustBe, this=or|that"); $validRepeaters = new PageArray(); $holders->each(function($holder) use($validRepeaters) { $validRepeaters->import($holder->myRepeaterField->find("INeed=toBeThis, and=that")); }); This is kinda similar to this one, but not exactly as pages could be selected in multiple pagefields, whereas repeaters are (without api usage) single selection only: https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/

The speed will most likely be far more dependent on the actual machine the thing (the db) is running on. As soon as the mysql query is constructed it's not in the hands of processwire (or any framework) to influence the speed of a query. But to say that I've no real stats about how fast the selector to mysql query conversion of processwire is. It's fast enough that nobody here seems to have issues with it.

The problem – as you're describing it – is trying to separate user-content from otherwise bootstrapped content. That's just not how it works. It's all content in pages and processwire does not care where it came from. You might set templates up to be only single use or other things, but in the end it's all pages. So you probably should not try to work/hack around that. Also db backups and dumps are almost never a sane way to update a production site as soon as any content is independently created on it, be it user or only client/editor changes. It's hardly a processwire specific problem. If you need things to not be manual updates you've probably not many more options than these. The common way for other web frameworks out there to have is to use migration files, which are files handling any "bootstrap" changes in the db and as they're files they simply are tracked by any used VCS and just run on each deployment. I've created a module to use this strategy with processwire: There's also a migrator module from adrian, which tries to solve the "migrating pages / templates / fields" issue, but I'm not sure if it can handle e.g. changes of module settings or installing new modules and such things: You could also look in non pw-specific migration tools like https://phinx.org/, but hand writing pw changes in mysql queries might not be fun. There's also this tool, which claims to track db changes, but I'm not sure how well it does work: http://dbv.vizuina.com/.

There's not even the need to manually count the number. foreach($page->children->getValues() as $key => $child) { if($key % 2 == 0) { // even } else { // odd } }

What I noticed is that CKE does simply strip buttons on mobile, leaving me without code blocks there.

Same could be said about any other currency which does have a bad conversion ratio to USD. Also while it hasn't been as bad as for the GBP the € also did get a hit in conversion rate. By now it's really not that bad for both of them as their conversion rates where at similar numbers (according to bloomberg) already earlier that year seemingly without anyone noticing.

I'd like to see that, too, especially as it's probably only left out because it wasn't part of the pw native implementation. Maybe we could just have a WireMailAttachments interface for that?!

At least. Better would still be to possibly return the actual number of sent emails.

No. 1 is a violation of the WireMail interface, which says send() should return an integer and not a boolean. This should rather be changed in the module than in user-code.

If you manipulate this method (the only one) in PagesPaginatorNoDuplicates.php you could log or otherwise store found pages/selectors for each separate part. The resulting list is just a pagearray, where new pages are appended one after another. protected function getItems($selector, $key, $start, $limit, $storage) { $selector = $selector . ", start=$start, limit=$limit, id!=$storage"; wire('log')->save('paginator', $selector); $pa = wire('pages')->find($selector); wire('log')->save('paginator', (string) $pa); return $pa; } The class(es) itself do not order things. It could be that $start / $limit values are off, but these are tested, so they should work. Could also be that some selector of yours is not working as you expect it.

If you're on a unix based system this might be also be a option: http://shapeshed.com/making-the-case-for-make/

include=hidden, status!=unpublished, Keep in mind that include=all will include a lot more than just unpublished pages.

Changing the value does only change the "maximum", but not the actual used value. That's why I said you should look for the places where the property is used. There you can find the actual process of determining the size of the image.

Laravel valet is also using caddy for their local webserver needs.

It's not random, but scaled to the modal window. Look for the $maxImageWidth property usage here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module

$pages->addHook('saved', function(){ $pages = $event->object; $page = $event->arguments(0); if($page->template != 'single-comment') return; $total = array_sum($pages->find("template=single_comment, indice_01!=''")->explode('indice_01')); $pages->get('/comments/')->setAndSave('totale_indice_01', $total); }); Just keep in mind that this won't scale well. It's loading all those pages at once with this. If you need a more scaleable alternative take a look at the new findMany in 2.8/3.0 or maybe even raw mysql counts/sums.

I'm not sure how you want the result to look like, but this is adding the number to the total each time you're saving a page, meaning I'll just get more and more on each save. If you really want to have a sum of those field's you'd need load all instances each time and sum them up to get a (probably more useful) value. Also here's a $ to much after the ->.

You can try these: https://davidwalsh.name/font-smoothing

Uhh, that sounds nice. I'm still eagerly waiting for the project to become stable. This might finally make the whole server setup setup less error-prone.