ryan

This is the sequence of code that gets executed before that error: $dir = wire('config')->uploadTmpDir;if(!$dir || !is_writable($dir)) $dir = ini_get('upload_tmp_dir'); if(!$dir || !is_writable($dir)) $dir = sys_get_temp_dir(); if(!$dir || !is_writable($dir)) throw new WireException("Error writing to $dir. Please define \$config->uploadTmpDir and ensure it is writable."); I don't think the trailing slash matters here, unless that causes Windows to return the wrong permissions for the directory (?). My best guess is that the values returned by both your PHP upload_tmp_dir and sys_get_temp_dir() are not writable or don't exist. Manually specifying the $config->uploadTmpDir would be the best course of action here.

Sounds interesting. Here's one way you can do it: $table = $fields->get('your_page_field')->getTable(); $query = $database->query("SELECT data FROM $table GROUP BY data"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $items = $pages->getById($ids); // $items is a PageArray echo $items->implode("\n", "<a href='{url}'>{title}</a>"); If we were to add this to the API, I think I'd want to make it accessible from a regular find() selector, rather than as a separate findSelectedPages method. That way it could be used with things like InputfieldSelector. Perhaps something like this: $pages->find("your_page_field=:selected"); ...where ":selected" is a keyword is would recognize to execute this behavior.

It does sound like a directory separator issue, but not really clear where. Can someone post a translation JSON file that has the issue?

When a field is only made viewable (whether by permissions or by the field's visibility setting), only its content is rendered in the document, not its form field. When it comes to visibility, field dependencies are a front-end/javascript task, so it needs that form field see what the value is. It doesn't work in your case because the field you are using for your dependency physically doesn't exist in the form (since it is not editable). In order to support this dependency scenario, we may need to add an option to allow rendering of the <input> rather than just the contents, similar to what we do for language field permissions. The user would still be able to change it (and affect the dependencies that way, though only on the front-end), but any changes they make to non-editable fields wouldn't be saved.

I was actually thinking of converting all feature request/enhancement issues to something in the PW website (powered by PW pages). Something like the sites directory, with the ability to "like" requests, so that the most requested ones could rise to the top and get more focus. This would also get them out of GitHub, so the focus there can be on issue reports. Though I think it's good to still submit feature requests at GitHub, but I would just move them to the more dedicated system and close them out there once that's done.

I'm not seeing the same error here. I setup a multiplier that uses "Textarea" and then populated values and did a search using the "%=" operator. It successfully located the page I put it on. Double check that your "field type to multiply" specified on the details tab for Multiplier is "Textarea". If it still doesn't work, what version PW and Multiplier are you using?

When it comes to output, options fields are designed to mimic the behavior of Page fields. So $option->title is the primary field you would access from each option when doing output, i.e. echo $page->myfield->title; Or if a multi-value field: foreach($page->myfield as $item) { echo "<li>$item->title</li>"; } Other properties you can access are 'id' and 'value'. In most cases, you will just be accessing the 'title' though. The 'value' property is only used if you defined separate values for your options, i.e. "id=value|title". When it comes to manipulating values, it's really simple. Just make sure that output formatting is OFF ahead of time (like Kixe mentioned above). This is true for any ProcessWire field where you intend to manipulate values. If output formatting is ON, then it's simply not going to work because the Page is not in a state to have it's values manipulated. So for those of you above where it didn't work, chances are your $page output formatting was on. Turn it off like this: $page->of(false); Assign the selected option title you want to to field directly (as a string value). This is just like previous examples on this page: $page->myfield = 'Yes'; If you want multiple selected options, then assign an array of option titles, i.e. $page->myfield = array('Yes', 'Maybe'); You can also use a string to set multiple titles (separated by a pipe "|"): $page->myfield = "Yes|Maybe"; You can also set by the option's 'id' or 'value' properties, using the same syntax as above. Note that when assigning positive numbers, they are always assumed to be the 'id'. So if your option 'title' or 'value' (if used) needs to be numeric, you might want to specifically assign your 'id' properties to be that same number to reduce confusion, i.e. "1=1". If using separate values and titles, it will look for a matching title first. If/when you want to save the changes, then follow it up with: $page->save(); // this $page->save('myfield'); // or this, if you don't need to save anything else

If you see a JS error form file upload, there's an way to find out exactly what the source of the error is, at least in Chrome. Open the developer tools in Chrome: View > Developer > Developer Tools. Click on the "Network" tab in these tools. You should see columns for "Name, Status, Type, Initiator, Size, Time, Timeline" (if you don't, drag your dev tools to be a little larger). Drag in a file to your file field that's not working, to attempt to upload. You'll see a new item appear at the bottom of your Network tab that looks like "?id=123", where 123 is the ID of the page you are uploading to. Click that "id?=123" item. It'll open a new panel to the right with several new tabs. Click the "Response" tab. In this Response tab, you'll see some kind of error message, likely followed by some JSON code. You may be able to tell what the next step is from the error message. For instance, maybe it's some 3rd party module reporting an error directly to output, or maybe it's a 403 error from Apache, indicating that mod_security is interfering with your file uploads. It could be anything. If you can't tell what to do next from the error, paste it all in here so we can get a better look and we can suggest what to try.

Antispambee sounds like a good one! Does it use some external library that is separate from the Wordpress Plugin? We actually do have a means of integrating more types of spam filters into comments, and it's via extending an abstract module class called CommentFilter. This is what CommentFilterAkismet extends, and we could add additional modules that also extend CommentFilter and implement the abstract methods. What's missing right now is for FieldtypeComments to check for additional CommentFilter modules. However, that was always the intention to expand it, and I'd be happy to add this capability, and maybe someone else can implement a new CommentFilterAntispambee or other(s) so that we've got more options here.

Evan, I think your solution is a good one, but it definitely leaves the question of why it's necessary on these particular installations. It's like the database changes got previously applied, but the schemaVersion stored with the $field didn't. I will add your changes, but also think it's hiding another issue that I'd like to find a way to reproduce so can determine the source of it. If anyone is able to reproduce on a fresh install, please let me know.

Just wondering if anyone has been able to duplicate this? Since I'm not able to duplicate locally, I'm having to look closely at the error messages: Did these two occur immediately after each other? On one hand it's saying the column doesn't exist. PW catches that, and attempts to add it. Then it's producing a "column already exists" error. So it's like the column both exists and doesn't exist at the same time. The next thing I would suggest is running a DB repair, as it sounds like something might be corrupted. Though I'm interested to hear if anyone else sees the same problem. We did have an issue here a couple months ago on the dev branch, but it was fixed. It's always possible that something about your DB still has a leftover from when there was a problem. I'm curious if you are able to duplicate the issue on a fresh installation of 2.6? A good way to test would be to install with the "languages" profile that it comes with. Thanks.

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).