LostKobrakai

Looks very nice. A few things I noticed: - The back/forward browser buttons won't always work - It's a bit strange that the back button on the news page is only at the bottom. I couldn't find a way back at first.

I just made the 0.3.0 version the new stable version. I've also added 0.3.1-beta with a new migration type: AccessMigration. This migration is only meant to change access rules for templates like shown below. List templates with changes, prepend a + or - if the useRoles setting does need to change. For those templates then list all roles which have changes (can be none) and supply which types of access should be added or removed. <?php class Migration_… extends AccessMigration { public static $description = "Update template access rules"; protected function getAccessChanges() { return [ '-blogpost' => [], // Remove useRoles from blogpost template '+basic-page' => [ // Add useRoles to basic-page 'subscriber' => ['+view'], 'editor' => ['+view', '+edit'], 'admin' => ['+view', '+edit', '+create'] // +create does require +edit ], 'tag' => [ 'subscriber' => ['-edit'], 'admin' => ['+full'] // view, edit, create and add ] ]; } } Edit: Had to remove the automatic +edit for +create, otherwise it's not clear to what to revert on rollbacks.

It's as complex as building such things on your own elsewhere. We have an easy pagination generating module, which just happens to lack an option to render just next/prev links instead of a full pagination. I'm sure Ryan could add those quite easily. Also may I suggest a more readable version of yours. Things are always easier to digest when they're not muddled with html tags. <?php $next = $prev = ''; $total_pages = ceil($pagedata->getTotal() / $limit); if($input->pageNum > $total_pages) // Optional; For page 11 of 10 throw new Wire404Exception(); if($total_pages > 1){ $base_url = rtrim($page->url . $input->urlSegmentsStr, '/') . '/'; if($input->pageNum == 2) $prev = $base_url; elseif($input->pageNum > 2) $prev = $base_url . $config->pageNumUrlPrefix . ($input->pageNum - 1); if($input->pageNum < $total_pages) $next = $base_url . $config->pageNumUrlPrefix . ($input->pageNum + 1); } ?> <?php if($next || $prev) : ?> <div class="pagination"> <?php if($prev): ?> <div class="prev-page"> <a rel="prev" href="<?= $prev ?>">Prev page</a> </div> <?php endif; if($next): ?> <div class="next-page"> <a rel="next" href="<?= $next ?>">Next page</a> </div> <?php endif; ?> </div> <?php endif; ?>

# and everything after that are technically not part of the site structure, but fragments in the (same) page (see links to #id). I'd imagine that site crawlers treat them as different pages, because of all those single page apps miss-using that for actually different pages.

Look at Inputfield::processInput, especially the first few lines.

And as likely to misuse. I don't want to say that it's not easier in some ways, but I fear that people – especially the target group, new to processwire, never heard of region api – misunderstand what it's meant for.

It certainly is possible, but there's currently not much processwire would give you out of the box in terms of an implementation. You'd need to write that on your own.

To be honest I'm not sure this will make things considerably easier to grasp for (new) people. I can already see people trying to use it as replacement for a templating language. I really don't think it's worth it just to not have a $main/$sidebar variable, especially for new people. I'd imagine it's more confusing than helping. I'd much rather would like to see a guide dedicated to examples of direct output -> delayed output -> separation business logic / view logic -> templating engine (twig/blade), what the benefits are and how to switch between them (e.g. same output in different strategies). Especially the third one is a kinda pet peeve of mine, because I went into the rabbit hole myself, where markup was so deeply coupled with processwire api stuff, that it was a nightmare to change anything. For me this seems to be more in line with your motto of teaching people how to fish.

/** * Global function, therefore does work everywhere, * but will always refer to the first pw instance * in case of multi instance usage. * Because of that it's discouraged to use this in * modules. */ wire("apivar") /** * Safest way to get the api variable in wire derived * classes like modules. */ $this->wire("apivar") /** * Does work as well, but some (core) classes have that * type of access disabled. It also prevents you from * using a custom paramater $apivar in your class. */ $this->apivar

There is a nginx.conf somewhere here in the forums. Just search for it on google.

mod_rewrite is a part of apache, so there's nothing to detect when this is using nginx. But you can still complete the installation with that error. Just make sure rewrites are correctly set up in nginx as well.

It doesn't because $config->adminThumbOptions is not an array, which you could manipulate. It's just a getter of an object. That's just how php works.

Can you explain a bit more why ProcessWire does get in the way of this dependency support? I mean your api could still map to paths using urlSegments.

Take a look at this discussion

Take an example by looking at multi value fields in processwire for your perms table: user_id,channel_id 1,1 1,2 1,5 … 2,3 2,4 2,7 … This allows you to join users and channels together by permissions. No need to parse any strings. This is even compatible to foreign key usage. And as this is a still a processwire forum: Why not model it by using pages

Source images are never converted or compressed on upload, besides if you force a max. size and the uploaded image is bigger. Only the thumbnails/variations generated from that source file will get compressed/converted according to your image sizing settings.

For your own classes nothing has to change. You can use your own includes / autoloading. ProcessWire 3.0/2.8 does have psr4 autoloading capabilities and you could use composer to autoload/include things like you could in 2.8.

In this case I'd vote for merging efforts than keeping it separate. Not only is is damn similar now, but I also don't see how those would differ more in the future.

It does not reorder, but it does detect missing page/parent pairs in the pages_parents table.

If you used the email for the name it does indeed work.

Then take a look at this one: https://github.com/processwire/processwire-issues/issues/136

What you want the system to do is simply not possible with core features. Image fields are file storage fields and even the description for them is more of a convenience functionality rather than a good way to store information. I've not used ImageExtra by now, so I'm not sure how it does save it's additional data, but it seems it doesn't do what you need as well. For such an image grid you should still go with single pages holding the image / thumbnail and additional info. Maybe you can use a pagetable to display those imagepages and keep the convenience of drag&drop / nice overview over items, which is not so nice with repeaters. If this is the case, how does that go together with each/lots of those images having custom made thumbnails as well? It probably either going to be a lot of manual uploading work or you strip the feature of custom thumbnails. If both is not possible you probably wont get around building something custom to create those grids.

Depends on where you're trying to use those values. Field values by default are only formatted while rendering templates. Otherwise (in hooks/modules) you'll most often get unformatted values, besides if they're called as part of the template rendering. If you want to be sure about things use these: $page->getFormatted('fieldName'); $page->getUnformatted('fieldName'); The latter one is the most useful because it's independent on how fields are set up.

I'd suggest using this (at least more descriptive version) and see if it fixes things: return $pages->find("has_parent=$page");

Each new field must be able to create it's own table and corresponding indexes. Few modules do create own tables as well.