ryan

@Ivan Gretsky Thanks for all the kind words! @bernhard I tried to duplicate the issue here on my Android phone (Nexus 6, Android 7.0, using Chrome) and do not see the effect you are seeing. In my case, the resize was identical to the one tested on desktop (OS X, Chrome). It looks like in your case, the one tested from your phone went a lot darker. I have a feeling it's got something to do with color, curve, gamma or level adjustments being applied by the phone (?) but curious to know what phone specifically, and what browser?

Client-side image resizing has been on our roadmap for awhile, and this week we've got it ready on the dev branch in version 3.0.63. People expressed interest in this feature in the comments to last week's post, and I promised to give it a closer look sooner rather than later. After getting that closer look, and doing some research, I realized we could get in this week's version. After using it now for a couple of days this week, I think people are really going to like this feature, and it works a lot better than I had originally guessed it could. https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/

Working with PNG and GIF now too. Looks really interesting! I'm impressed with how far you've taken this already. Is this a fairly common need? (chunked uploads). I'm not sure I've come across a case where I would have used this on a site before, but I imagine there are cases this could be a real life saver. Really cool libraries! Probably too much for our needs in the admin, but seems like a lot of great potential for modules here.

I started experimenting this morning. It's not all that difficult to get going. Proof-of-concept up and running already, so should have this functional on the core dev branch this week hopefully. (note: works for JPGs only)

Most of our image/file features have been developed by the community rather than me, and I'm guessing this will follow a similar path. It doesn't seem to come up very often, but since you've mentioned it here maybe we'll have to bring more focus to it. I'll try to get a closer look this week to get a better idea of when we might be able to get more momentum going here. I do agree it would be a nice thing to have sooner rather than later. Also, since you quoted both 2016 and 2017 roadmap, it's important to note that this is a roadmap. It is a list of goals, it is not a contract of promises. We never expect to be able to accomplish all the goals, but feel it's important to have them nevertheless. Always good to aim for more rather than less. What doesn't get completed in one year still stays on the roadmap for the next year, unless it's determined it shouldn't be for some reason.

Speaking for my modules only, I'm marketing these as turn-key modules, not as API tools. With the exception of the ProfilerPro module and Likes modules, the Pro modules that I develop were never intended as primarily API programming modules. They are modules that, outside of output generation, are meant to be largely turn-key, without little or no coding needed. It is true that you can use them at the coding level to do lots of things, they have an API and hooks available, and we could write an encyclopedia worth of content to cover it all. And it's also true that there are a few people, perhaps 5% of the users, that pursue this kind of stuff with these modules (especially Robin S., Adrian, LostKobrakai). I think that's great, and I'm happy to support that for those that are interested in using them that way, and have been for a long time via the support boards. This is a welcome and valuable audience for these modules, but not the primary or intended audience. The intention with most of the Pro modules is to provide things you can install and start using, and not have to code around. The documentation is consistent with the audience and intention of the modules. For those that want to get into the code side, I welcome it, but prefer to support them via the support board and focus in specifically on their needs. Though in the ProFields modules we do cover a lot of API side stuff too. The code of the modules is also well documented with phpdoc as well, making it handy in an IDE environment. If I develop a module intended primarily for API usage in the future, then of course the approach would be different. But because that doesn't describe my current Pro modules, I prefer to support people individually when they want to pursue unique needs that might require additional code, as everyone's needs are slightly different. That's beautifully put together– joshuag is an amazing designer and front-end framework developer, and there's no way I could ever compete with his skills in those areas. Sorry about that, but that's just reality. I can make great modules, but I'm far more developer than designer and marketer. I gave up trying to be a designer long ago. Also should mention though that what he's marketing clearly has a larger API-side than what's intended for any of my modules. And I agree he's outlined everything really nicely. I feel that I covered everything about the product pretty exhaustively. What do you think is lacking? https://processwire.com/api/modules/lister-pro/ Actions are just one small part of ListerPro, but it comes with seven actions, including an action that's a template for creating your own. Also why the surprise (?), the ListerPro page outlines all of the seven actions here. Have you seen this? https://processwire.com/api/modules/profields/ I don't use this one very often, and may delete it. It started back before we had an on-site store, so isn't really needed anymore, as it's been replaced by our store. They are not outdated. As far as the information goes about the modules, they are fully relevant and up-to-date. Though I should mention I always try to provide more than I market, and feel this is a good thing. I like for people to feel that they got something more and better than what they expected, with everything I do.

This week we’ve got ProcessWire 2.8.62 (corresponding to 3.0.62 master), a look at some current work-in-progress, and some nice momentum in ProcessWire usage and market share. https://processwire.com/blog/posts/new-2.8-version-current-projects-and-pw-usage/

Peter, it sounds like you might have an older version of the ProcessWireUpgrade module. It had a bug in it that PHP versions prior to 7.x appear to have ignored, so it doesn't show up except in PHP 7.x versions. If you grab the current version of the ProcessWireUpgrade module and replace the files in /site/modules/ProcessWireUpgrade/, that should fix it. Alternatively, you could just delete the module files and install the upgrade later. If neither of these fixes it, try deleting the /site/assets/cache/FileCompiler/ directory as well.

While a relatively quiet week due to travel, the 3.0.62 version has been merged from dev to master, plus a few other small updates in this week's blog post: https://processwire.com/blog/posts/pw-3.0.62-master/

This post covers what’s in ProcessWire 3.0.62 and provides an in-depth look at the final spec of markup regions, how they work, and how to use them. https://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/

Hi Fred, here's some code that might be helpful. Also, make sure page numbers are enabled on the page's template (URLs tab in Setup > Templates > any-template). $limit = 10; $items = $pages->find("template=something, sort=name, limit=$limit"); $total = $items->getTotal(); if($total) { // there are results present $numPaginations = ceil($total / $limit); $pageNum = $input->pageNum(); if($pageNum == $numPaginations) { // you are on the last page of results } else if($pageNum == 1) { // you are on the first page of results } else if($pageNum > $numPaginations) { // beyond the last page, do a redirect or a 404 } else { // somewhere in the middle of the paginations } } else { // there were no results on any pagination } Also see the PaginatedArray type (PageArray is a PaginatedArray): http://processwire.com/api/ref/paginated-array/

This week we’ve got lots of details on our successful migration to Amazon AWS services for the processwire.com network of sites. We've also got updates on the current core and ProDrafts status. https://processwire.com/blog/posts/amazon-aws-now-powering-processwire.com-sites/

This week we've merged the dev branch to the master branch for ProcessWire version 3.0.61 master. This replaces the existing master version 3.0.42. What's the difference between 3.0.42 and 3.0.61? Quite a lot! In fact, we might usually call this a major version and just name it ProcessWire 3.1, but we're saving that version number for when we get at least the new Regular site profile included (and perhaps the new admin theme), after Uikit 3.0 is out of beta. In this post, we'll cover some of what's new with ProcessWire 3.0.61 relative to the previous master version… https://processwire.com/blog/posts/processwire-3.0.61-master/

Thanks–fixed. The API reference is already showing all the docs available for each method, so linking to line numbers would focus in on the actual code/implementation behind the method, rather than the documentation. When it comes to docs, it's about the interface, not the implementation. The interfaces rarely change, whereas the implementations change all the time. Coding towards something other the method's interface could be problematic. That's why I think the code-behind-the-method probably shouldn't be part of the documentation, except maybe in cases where the docs suggest looking at the method directly. This refreshes once every 24 hours. This is not intended, I'll fix this–thanks. Btw the "c=" indicates number of changed fields when possible, but mainly c=0 means no changes, and c=1 means there were changes.

This week we have ProcessWire 3.0.60, which is likely to be our next master version. We’ve also got a few more Pro module updates, as well as a major update to our online API reference… https://processwire.com/blog/posts/processwire-3.0.60-core-updates-and-more/

The latest core dev branch coming soon to the master branch, plus several Pro module updates and more. https://processwire.com/blog/posts/processwire-3.0.59-module-updates-and-more/

While mostly just routine updates, this week we have a new core version on the dev branch with several tweaks and PRs. Work also continues on the Uikit admin theme framework, and more: https://processwire.com/blog/posts/processwire-3.0.58-core-updates/

This week, some more layout options have been added to it that I think many may find useful. This post highlights them with a screencast: https://processwire.com/blog/posts/processwire-3.0.57-and-admin-theme-framework-updates/

This week we have a new core version on the development branch and some nice updates to our Uikit admin theme in development. This post covers them in detail, includes a screencast and links to a live demo of the updates. https://processwire.com/blog/posts/processwire-3.0.56-and-uikit-admin-theme-updates/

This week we’ve got a new core version on the dev branch (3.0.55). This version has a whole bunch of fixes and adjustments. It also adds a new drop-down page tree that we cover in more detail in this blog post. https://processwire.com/blog/posts/processwire-3.0.55-core-updates/

No problem – I've updated the "regular" demo site to use this latest version of the admin. It's not all that different from the one that was there, but does have the new offcanvas nav and several other minor tweaks that weren't present before. If you check it out, and you checked out the previous iteration, you probably want to clear your cache or login with incognito mode, as the demo site has some aggressive cache control headers and I neglected to update the css/js version links. http://demo.processwire.com/regular/processwire/ u: bloguser p: processwire3

Last week’s post indicated we may have the first [beta] version of the Uikit admin theme ready, and I’m glad to report that we’ve now got it ready for download on GitHub. In this post, we’ll describe what’s new, how to install it, and how to develop with it. https://processwire.com/blog/posts/processwire-3.0.54-and-adminthemeuikit/

@vwatson I was able to duplicate this issue when selecting text in a <td> and dragging the selection a little bit past the actual text. What I found is that you've got to be really careful with the link selection in a table cell, or else CKEditor will include part of the <td> element in the selection. The result is that when inserting a link of that selection, you get an invalid link, which isn't allowed there, so CKE moves it above the table. So far I can't figure out how to automatically modify that selection to narrow it in, but I did figure out how to detect it and cancel the action. I've also set it to show an alert box telling you to re-try the selection. This at least prevents the insertion of the invalid link. Please replace your /wire/modules/InputfieldCKEditor/plugins/pwlink/ directory with the contents of the attached ZIP file. Do you find this also resolves the issue there? Thanks. pwlink.zip

This week we've got a demo setup of the admin theme framework that's been written about in the last two weeks of posts. Read all about it here and try it out from our demo site– https://processwire.com/blog/posts/demo-of-admin-theme-framework/

Marc, it sounds like you've got a bottleneck somewhere. You mentioned a remote DB connection, and maybe there's something to to that. You also mentioned Windows (I'm in unix), and it's certainly possible there's something platform specific going on. Here are some things you can do to narrow in on where it might be. Edit your /index.php file and before the line that says this: $config = ProcessWire::buildConfig($rootPath); Add this: Debug::timer('pwboot'); Now edit your /site/templates/_init.php file (or whatever gets called first) and add this at the top, after the "namespace ProcessWire;" (old school and rough, but gets straight to the point): die('Boot time: ' . (Debug::timer('pwboot')*1000) . ' ms'); Now you can get a sense of how long it takes ProcessWire to boot, before it hands off the request to you. This should give you an indicator as to whether you need to look at the modules you've got installed, or whether you need to look at the API calls in your templates. Hit reload several times in your site (front-end) to get a sense of the average boot time. On my oldish Macbook Pro and PHP 7, running the site-default profile with no 3rd party modules installed, these are my average boot times: ProcessWire 3.0.52: 53 ms (opcache off) ProcessWire 2.7.3: 104 ms (opcache off) ProcessWire 3.0.52: 35 ms (opcache on) ProcessWire 2.7.3: 35 ms (opcache on) As you can see, without PHP caching the code, ProcessWire 3.x boots nearly twice as fast as ProcessWire 2.7 (at least in my environment). Interestingly, if PHP's cache is enabled, then the boot time is identical. But when Soma said above “ProcessWire is getting slower and slower each iteration”, this is a blanket statement that is the opposite of reality. ProcessWire is getting faster and more optimized with each version. What's real is that clearly something about the conditions present in his environment and your environment is reducing performance, and that needs to be narrowed in upon. So the next steps will be to determine if it's something about the server, something from a module, or something going on in the template file(s), like some specific API call that might be common among your installations. Now go to your Chrome dev tools, Network tab. Hit reload several times like you did before (same URL). Note the first request in your Network tab. Take this time and subtract the time you recorded above. This represents (roughly) the time required to load PHP before it gets to ProcessWire. With opcache off, my PHP takes about 100ms before it loads ProcessWire's /index.php file. If I enable opcache, then I'm seeing almost no overhead from PHP at all. Meaning, Chrome dev tools is showing 40ms or less. I'm guessing that your remote DB connection is going to mean your boot times are significantly higher than if it was local. So maybe you shouldn't be looking for the same boot times that I'm seeing here. But hopefully you can get a better idea of whether the times you are seeing are related to the boot process, or what happens after the boot process. If you are seeing it in the boot process, then uninstall all 3rd party modules and test again. Or go one-by-one until you can narrow in on which one it is. If still seeing a slow boot then we might need to start looking at potential Windows platform issues. If your boot times seem reasonable, then the next step is to start debugging in the template files. Let me know what you find and I can suggest the next steps.