ryan

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

We think it's an issue between the latest Chrome and TypeKit, as we haven't heard of it occurring in any other browsers. Also haven't heard of it re-occuring after a refresh, so most likely they made some change at TypeKit that needed a JS refresh. Though please let me know if it continues to recur, or if anyone else sees it occur in any other browser.

I'm definitely seeing old cached stuff there, or remnants from the old admin theme. Particularly on that uninstall box, the colors of the PW 2.3 admin theme are bleeding through. Do a hard refresh on your browser cache. Make sure that your entire /wire/ directory was replaced in it's entirety and not replaced into (with potentially merged files). Lastly, make sure you don't have a /site/templates-admin/ directory present.

@justb3a I'm using PHP 5.6 here but not seeing the issue. It looks like something is throwing some output when it shouldn't, causing it to interfere with the resulting JSON from the ajax request. You can observe what it is by clicking your Network tab (from your screenshot above) and then click on the ajax request that resulted from your upload. From there you can observe details about the request. Click on the response tab, which should give you a plain text view of the response. Most likely you'll see an error message (or some other HTML output) preceding the JSON. What does it say?

Looks like a bad typo on my part, sorry guys. I've corrected it.

Actually it gets even simpler than that: $statusLabels = $page->status(true); $statusLabels is an array of names/labels applicable to the page.

I just pushed an update to the module that corrects the issue. This module used a naming format for a file that's not compatible with PW 2.5.11+ (though sounds like it still may have worked up until the latest, but really shouldn't have). If you grab the latest it should work now.

@en4ce, thanks for getting ProCache. I am guessing that your order was placed under a different account than the one you are logged in with now, because there's no order connected at present. If you can send me a PM or email (ryan@processwire.com) with your key and any order information you received, I can connect it with your account and get you setup asap. Thanks.

I saw Adrian's GitHub issue report and just pushed a fix to dev (core) for this. It was attempting to count the number of populated rows, and of course there can't be any. Now it checks to see if the Fieldtype lacks a table definition (schema) before attempting to count rows. I suppose this only affects FieldtypeConcat, but it's possible other Fieldtypes in the future may not need their own table for one reason or another.

You are absolutely right. Either that, or the find() that locates those pages should only include the pages that have a value set. I will go in and update this now. Thank you for going into the detail you did here, as I had not considered that issue before so this is a big help.

I know there are benefits and drawbacks to different approaches, so I'll try to explain why PW uses the approach it does, and respond to some of the points above. The approach described as an alternative here is similar to what I've used on other projects, including PW1. I was really looking to come up with something different for PW2. The goal was to make it as absolutely simple as possible for people to add hooks and for people to make methods hookable. I wanted it to be in the background and everywhere, so that you really didn't even have to think about it. It's not designed for ease of consumption by xdebug, I'll give you that. But it is designed for ease of consumption by you and me, which I consider more important. Admittedly I don't use xdebug very much anymore, so designing things for xdebug has not been a priority. When you start a new CMS project, you are in a crowded space, so you have to come up with things that are different. So one of the ways ProcessWire differentiates itself is by making hooks easier to hook into and create than they are in other platforms, and I'd like to keep to that. When it comes to PW's code base, I consider it important to not add complexity purely for sake of static analysis. From my perspective, static analysis is a good thing, and I'm more than happy to let it dictate the direction of comments and what supports the code. But when it starts to dictate the direction of the actual code towards unnecessary complexity/verbosity, less efficiency or reduce the simplicity of the API, then I consider it no longer helpful. If ProcessWire were just a PHP framework and coders in IDEs were the primary audience, then I would feel differently. But for ProcessWire's audience and growth, when I'm confronted either making my IDE happy (and related tools like xdebug), or making the API (or related things like hook system) as simple and as good as they can be, I'm always going to choose what's best for PW's API and systems. My preference is making both happy. But when you are doing something different, existing tools won't always be familiar with it. For something like the hook system, there was definitely a conscious decision to go with what's best for PW and PW users, over what's best for static analysis or xdebug. All the add hook methods are actually handled by just one method: addHook(). The point of the other methods (mentioned below) is to make things simpler for you, and make your code more readable. I prefer verbose method names to boolean and array arguments because they are self describing. think this is a benefit, not a drawback. Use addHook() if you want to add a method to a class that isn't already there. Use addHookProperty() if you want to add a property (rather than a method) to a class. Use addHookBefore() if you want to hook before an existing method (and have the option of modifying arguments sent to it). Use addHookAfter() if you want to hook after an existing method (and have the option of modifying the return value). Regarding the distinction of hooking a class name or an object, this is also meant to be a help to you: The purpose of being able to call a hook on a class name is so that you can hook ALL instances of that class (current and future). The purpose of being able to call a hook on an object is to hook only that single instance of the object. As for ease of finding hooks, this is also something I've tried to make as simple as possible by using a convention that you won't see elsewhere in ProcessWire: 3 underscores prepended to a method. So while you can use CaptainHook, I'm not sure you need to, because you can find all hookable methods in ProcessWire simply by doing a search for 3 underscores "___". A recursive grep is one easy way to accomplish that. Page::render() is actually a very unique case that you won't see elsewhere in PW (that I can think of). Usually I would have just put a method like that directly in a class and have it handle the render from there (or have the method there to call up the PageRender module). But PW started out as fully API driven, where there was no such thing as "render" of anything, to the core. So the ability to "render" anything was seen as something specific to the web context of a CMS. That's ProcessWire now, but its roots are pure CMF. Today, I would likely just put that render() method directly in the Page class. But I also don't see any reason to move what's already working there, as it really makes no difference in how it works. And you can still hook Page::render if you want to, just like it actually did exist in the Page class. Because you can't actually see a Page::render() method in the class, we use phpdoc at the top of the file for it. I would love to make everything hookable, but the reality is that there is a little overhead associated with every hook (in any hook system). So I don't usually make methods hookable unless there is a request for it to be. We started with very few hooks, and now we have quite a lot. But the majority of the hookable methods you see in PW today are the result of people asking for them to be hookable. And luckily, it's very easy to do just that: just append 3 underscores, and you are done. I would answer this pretty much the same way as the Hookability point above. When more granularity is needed somewhere, we add it, and there's lots of examples throughout the core. But it's hard to know where one might need that until it is asked for somewhere specific. When a module like ProcessPageEdit was originally written, I honestly didn't know if anyone would ever want to hook anything in it at all. Over time, it has become more granular, and over more time will become even more so I'm sure, but only when specific needs for granularity/hooks come up. I love flexibility, but I also love efficiency. If everything in ProcessWire was fully granular and hookable PW might be very flexible for someone looking to hook specific things, but it would also be bloated and slow. My preference is to make specific things more granular and hookable when it will solve someone's specific need. Granted, there are plenty of hooks in PW already that nobody is using, but they are generally in places where it makes no difference in terms of efficiency. I'm not suggesting that hooks aren't efficient – there's very little overhead from hooks. It's just that if you multiply a very little overhead over thousands or hundreds of thousands of calls, then it becomes something. Are there any examples? I've tried to cover all potentially useful state changes with hooks, even if they aren't actively used. For instance, see the large set of hookable methods at the bottom of the Pages class. You'll see similarly named methods in any core class that deals with state changes (like Fields and Templates for example). Though it's also possible I've misunderstood what you mean.

Probably not a PHP 5.4 requirement till PW 3.0. Still too many PHP 5.3 systems out there. Though great to see lots of momentum with PHP versions (5.6 is great).

If this were a files/images field and you had 2m pages of data, you might have to take extra measures. But from what I can see, you are just removing an integer field. ProcessWire should be able to do this quickly, so long as you are running an up-to-date version. What version are you running? Have a look in /wire/core/Fields.php at the method ___deleteFieldDataByTemplate(). That's what is executing this. It has two options, the slow one, and the fast one. The slow one cycles through each page with the field and asks the Fieldtype module to handle the deletion. This is required for fields that have other assets that might need to be deleted too, like files or images. But for a field like an integer, it can use the fast method, which goes directly into the database and deletes it all with one query (which should just take a second). My guess is that the version of PW you are running is old enough to only have the slow method, or that for some reason or another the slow method is getting used when it shouldn't. The slow method would almost certainly fail in trying to deal with 2m pages, so I'm pretty sure that's what we're seeing here. So check your PW version. You may be able to resolve this simply by upgrading. If that's not it, let me know and we can look at other options.

page-edit-created is an optional permission that you can choose to create yourself in Access > Permissions. You would use this permission if you wanted a user to only be able to edit specific pages that they had created, or that you assigned to them.* For instance, lets say you had a blog with multiple contributors. All the blog posts use the same blog-post template. Then lets say you had a role named contributor. That role has page-edit permission. Your blog-post template (Setup > templates > blog-post > Access) has that contributor role assigned for "can edit pages" and "can create pages". The template used by the parent of the blog /posts/ (template blog-posts) would have "can add pages" assigned as the only permission on the access tab. If you've got the setup above, then users with the contributor role can edit any of the blog-post pages. But if you then add page-edit-created permission to the contributor role, suddenly those users can only edit blog-post pages that they created (or that you assigned them as the created user*). They can't edit blog post pages that other users created. To take the example one step further, add another new permission called page-publish (in Access > Permissions), but don't assign it to the contributor role. Now those contributor users can create blog-post pages, but not publish them. At this point, you've got a nice workflow setup where you as the administrator (or someone else you assign) has to approve those blog posts before they are published. *To adjust the "created user" on specific pages, see the setting under Setup > Templates > [your-template] > Advanced > Template Toggles > Allow created user to be changed on pages? Once that box is checked, you can change the "created user" on any page from the Settings tab. Not positive I understand the questions, but if i did then what I wrote above answers these as well. They are different permissions that do different things, so there's isn't crossover. But page-publish requires page-edit, so page-publish does nothing without a user first having page-edit on the same role. If your system has a page-publish permission, and a user doesn't have it in their role(s), then they can only edit unpublished pages (or create them if you assigned that ability somewhere).

You should be able to set permanent=false in your module info, and then in your admin do a Modules > Refresh. But if that doesn't do it, you could always update the 'flags' column for that module to be 0 (in the modules table), and then after a Modules > Refresh it should definitely let you uninstall/remove it.

If I view the source, your admin theme has all the following (at least on the login page) that isn't present in PW's admin theme. There may be more but this is just what I observed on a brief glance: <link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png"><link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png"> <link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png"> <link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png"> <link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png"> <link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png"> <link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png"> <link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png"> <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png"> <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32"> <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192"> <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96"> <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16"> <link rel="manifest" href="/manifest.json"> <meta name="msapplication-TileColor" content="#ffffff"> <meta name="msapplication-TileImage" content="/mstile-144x144.png"> <meta name="theme-color" content="#ffffff"> <link rel="stylesheet" href="/wire/modules/AdminTheme/AdminThemeDefault/styles/override.css"/> While none of these are likely to be the source of the problem, it does indicate that core files have been changed. So in debugging this, the first thing you should do is restore the core to a fresh version with no modifications (you can always go back). If you need to present a custom admin theme to the client, put it back in after the problem is resolved, and put it in /site/modules/ so that you aren't delivering something to the client that can never be upgraded. Even something as simple as changing the character set on a core file could cause problems. The issue you are seeing most likely is something interfering with the http headers, which could be as simple as a core file that changed character sets and now has some invisible character preceding an opening PHP tag at the top of a file. That may not be it either, but since you are seeing an issue here that has not turned up in PW before, definitely get a fresh copy of the core before debugging further.

Just reading your additional responses. Interesting that it doesn't affect all users. Try setting $config->sessionFingerprint to false, as perhaps the logout is the result of a dynamic IP address change or something in the user agent string changing. Though if the logout only occurs on one page, that still points to something up with that particular page. I'm actually wondering about something on the server outside of PW, like mod_security or similar messing with the session due to a combination of factors present on that page.

I think this forum software may have been made before the newer longer email addresses, but I'm sure they'll account for that in a future update. A lot of email address validators currently validate the last portion as being between 2 and 4 characters, and I'm guessing that's the case with IP.Board. That reminds me, I need to go double check that PW's $sanitizer->email() isn't one of them. The first thing I'd suggest doing is enabling debug mode by editing /site/config.php and setting the $config->debug=true; That should enable any obvious errors to appear on the screen. Getting logged out from a particular page suggests that some kind of output is occurring before the http headers, causing the session cookies to be lost. Remember to turn debug mode back off once you've tested things out to see if there are any errors being suppressed. Your admin theme appears to be heavily modified (found the admin login page), so that's one thing to look at. Restore the non-modified admin theme, by replacing the /wire/modules/AdminTheme/AdminThemeDefault/ with the original. Move your modified version to /site/modules/AdminThemeCaelan/ (or something like that) so that you can install core upgrades without losing your modified admin theme. The same goes for any core module–if you need to modify it, copy it to /site/modules/ModuleName/ and work with that instead. Otherwise you'll lose all your changes every time you upgrade PW. Speaking of upgrades, you might also want to upgrade to the latest PW dev version 2.5.20, as it contains a lot of fixes and enhancements that your site may benefit from. Though the issue you mention with logouts is not one I've heard of before. But it's worth a try. If none of this helps feel free to PM me a login so that I can take a look at the page in question and I can examine the http headers to see what is causing the session to break.

I found out this week that Google still has the "basic" calendar feed open. We know the "full" calendar feed has been gone since November, and I hadn't read anything about any of them still being open. So I have no idea if the basic one was re-opened, or if it's always been open, but it's there and fully accessible. Maybe this is common knowledge, but it's news to me–I found out about it just experimenting with Google's URLs. It's a much bigger pain to pull the data from than the "full" one since most of the data is not structured, so it has to be parsed out with regular expressions. But I went ahead and updated this module to support the basic feed, as it has all the data that we need in it. It's now ready to use in the latest update (v2.0.0). It looks like the "basic" feed also accepts all of our date and keyword queries too, which is great. As far as I can tell, it returns this module to a fully functional state with all features working once again. I'm guessing that because we have to parse the data with regex's that much of it may not translate to Google calendars in other languages than English, so that's something to be aware of. But if anyone comes across any examples I can always see what might be necessary to add support.

I've been looking for a fix for this, thanks! Just tested locally and seems to work nicely. I will update the other modals as well.

Yes this is default enabled on all image fields. I don't see any reason to have it disabled. Comments manager is only in the core dev branch. Once that becomes the new master, I'll likely remove the latest comments module from the directory. No plans to integrate at present. The crop feature added here is something entirely different from CroppableImage, and predefined crops are really the specialty of CroppableImage, which does a great job of it. The crop feature added to the core is more about getting the main/source image right, like for clients that don't have any image editing tools on their computer. It's particularly helpful in having some control over whatever variations might be created on the front-end of your site. For example: we are building a company directory and people upload various sizes of images for different people and sometimes people's heads get cut off in some variations. I'm using a square thumbnail on the listing page, and client uploads a tall portrait image. Head gets chopped off on the square thumbnail. Now the client can see "oh there's a problem there" and fix it themselves rather than calling me. That likewise fixes it for any other variations that might be generated from the same source image. No accounting for any of this is necessary in the site's code. Now I could use CroppableImage too, but I don't need this level of control for most of the images in the scenario I described, and don't want to make any changes to my site's front-end code to support it. Just want to give the client the ability to fix their own problem images when they pop up. Not looking to replace CroppableImage, which is already awesome and a great tool to use when your need calls for predefined crops.

That's just part of the stylesheet in AdminThemeReno. It doesn't do that in AdminThemeDefault. We can ask Renobird about maybe changing it. I don't mind the uppercase myself, but it does seem maybe a little large when it's displaying anything other than a short title. It wasn't coded to retain align classes through cropping, but I suppose it could. I'll look into it. That was actually fixed about an hour ago (https://github.com/ryancramerdesign/ProcessWire/commit/bdf74054b3da06b1b354189381ed8c2f191b857a). I'd never seen it myself till I uploaded this version to a client site and tested it out, and then suddenly got that error for the first time. Getting those plugin.js files out of your browser cache can be a pain though. You may have to clear your cache or quit/reopen the browser. Just tested and it doesn't. Looks like CroppableImage overrides the methods where this stuff is generated in InputfieldImage. However, it would likely be as easy as Horst just adding a single edit link to the output of CroppableImage.

The other half of the images update is now in place on the dev branch. This enables you to edit images directly from the images list that you see when editing a page. When you hover an image or image thumbnail, you'll now see an edit icon appear in the upper left corner of the image. Click it and a modal opens. From there you can crop and resize, and replace the original image, or save it out to an entirely new image (copy). When cropping and then replacing an image, it will also attempt to re-create any size variations to reflect the new crop. This update also includes tweaks and improvements to what was posted last week. I'll cover this all in more detail in Friday's blog post, likely with a short screencast too. But wanted to go ahead and mention that it's there now if anyone is interested in testing it out. If you do test it out, do a Modules > Refresh in your admin after installing the latest dev version. This will make it update the versioned JS/CSS links to ensure your browser isn't still serving older versions. Though sometimes it still takes quitting/reopening the browser or clearing the browser cache. Please let me know how it works out for you.

Actually they can place the images anywhere they want to in the text. They aren't limited to just placing it at the top. Of course, when you find where you want to place the image in the text, then at that point you have to specify whether its an image that should be left aligned, right aligned, or centered. On the front-end, you can choose how you want to handle that. While most of the time the text floats around it, sometimes I'll take an alignment and make it pull into a blank left/right column. Images for predefined placement in a layout shouldn't go in the text at all. You'd want to have a dedicated field or tag for those images. If there are more than a couple predefined placements, I might use tags so that an image with the tag "hero" automatically goes to your dedicated hero spot, etc. I usually treat galleries as predefined placements (like appearing above or below the main content). Rarely does the need arise where galleries need to be part of the actual copy, but others may have a different need/experience, so I think that's a good example. While I like having a consistent placement for a major feature like that, it's really more about having markup that is generated dynamically when the page is viewed. But if you wanted the ability to place galleries of images in-between blocks of copy, then I agree that's a good use case for a block editor. Whether it's worth the compromise would depend on the need I suppose. Perhaps that's a great case for a hybrid editor that is primarily RTE but provides certain blocks you can work with. CKEditor does actually provide something called Widgets that allow insertion of more complex predefined markup elements, but I don't think it's quite there enough to where I'd want to use it for a gallery. That's because it's something I'd want to generate on the front-end rather than directly in the RTE-generated markup. I don't like RTE's generating anything other than basic markup because it's just not as portable... once you start using CKE widgets, you can't really switch to another RTE without losing those widgets. Probably what would be ideal is CKEditor with a block-editor style select input at the bottom that lets you add certain types of elements like galleries, paginations, or other things (but not simple markup elements like headlines), and then lets you continue the text content underneath in another CKE instance. That would let the RTE do what it's good at, and let blocks handle the things that would benefit from having their markup generated at runtime (like a gallery).

This was also part of the update, but not yet finished. It'll be finished in this week's update. If you want a preview of what it does, you can click on the filename of any image (currently hidden that way, since it's not yet fully functional). It'll let you size and crop it just like in the RTE version, and then give you the option to replace the original or save as a new copy. But if you try it, no need to send issue reports just yet because it's only a work in progress at this point (the code just isn't there yet). Btw, it's not a replacement for CroppableImage, so if you have that need, you'll still want to use CroppableImage. The tool being added is purely about manipulating the base images in the image field, not about creating predefined/named variations to pull on the front-end. Though manipulating the base image may be exactly what you need to keep your api-generated variations from copping off someone's head, etc