ryan

Evan, it's actually not specific to MySQL 5.6 per se, but rather MySQL's sql_mode setting. We're seeing some strict sql_mode settings are a lot more common in MySQL 5.6 than in 5.5. I'm now running with them on my development environment and have fixed a couple spots in the core that were potentially issues with these sql modes. Though I'm not aware of any spots on FormBuilder that were potential issues with these sql modes. You mentioned that you were already running PW 2.5 though, so I honestly don't know what it could be. I've tried to duplicate it locally but so far can't. Can you give me more info on the steps you took and exactly when the error message appeared? It sounded like immediately after creating a form (i.e. entering the form name and clicking submit), but just wanted to confirm?

Wow, awesome site Nico!

Correct me if I'm wrong, but doesn't SHIFT+CMD+V (Mac) or SHIFT+CTRL+V (Windows) force paste as plain text in almost any application? That's the way I've always done it and it generally works well. No need for extra plugins to do this when that capability should already be OS native.

Sorry for my late reply to this. First question here would by why not just select Roles and then choose "newuser" in the select box? It doesn't seem like it's necessary to use custom (field=value) here. However, if you want or need to use custom (field=value) for some reason, then you would need to specify the property of roles that you are trying to match because "roles=" would require an integer of the role ID. I think what you intended was "roles.name=newuser" ? However, I really recommend just choosing "Roles" as your field and then select "newuser". Are you sure that "testuser" session had ended? (i.e. logged out and logged back in?). DynamicRoles caches some information about the user's access within the session (server side) at login. There's no way that the user can change that since it is all server side, but if you are making big changes to the access for a user that's logged in, they may not see those changes till their next session. Or you could clear the server side session files/db to force clearing of the cache. But I'll assume you may have already tried logout/login, so unless I hear back I'll try to duplicate here. I've not been able to duplicate that here, but I do think I know how to fix it. Go to the DynamicRoles module settings and select the fields that should appear in your dynamic roles listing. It looks like you've got Title selected right now, which you don't want (since there is no title for dynamic roles). I would suggest selecting name and permissions. Please let me know if that fixes it?

Actually pretty much everything has been moved to /wire/config.php, leaving /site/config.php exclusively for things that you want to modify from the defaults. You'll notice that /site/config.php pretty much contains nothing now other than debug and the settings added by the installer. However, any config property can still be modified from your /site/config.php file. See the /wire/config.php for a full reference of all possible properties you can customize.

A few updates in response to the PDF that was posted earlier. More to come, but this is a start. Currently these are just on dev, but will be merged to master soon. The main README file has been updated with a link to the HTML version at the very top. I honestly think including a README.html file in the core itself is bad form because it reveals exactly what software is running the site. Some might have noticed our README files are generally blocked from http access (by the .htaccess file) for this very reason. So I think putting a link to the HTML version of the document at the top of the Markdown file is a good compromise. The default site profile has been updated with its own README file and separately hosted HTML version: Introduction to the default site profile, which goes in depth in explaining exactly how the site profile works. The template files have also been updated, telling the user to see README.txt for more information (though not sure that's really necessary).

Best bet is to do exactly what the warning message tells you. Remove /site/modules/InputfieldCKEditor/ and /site/modules/MarkupHTMLPurifier/. After that, click on "Check for new modules" and PW should then be able to see your new core versions. It's certainly possible it is related to you having an older CKEditor. We have some communication going on between CKEditor and the language tabs, so if you are trying to run an older CKEditor with the newest PW 2.5 then you will likely get JS errors, which could produce the effect you saw. Another thing to double check is that you don't have an older language tabs module installed. Check your Modules > Site just in case. Lastly, hit reload/refresh once or twice on the page, just in case it's a browser cache thing. I tested the CropImage/Thumbnails module with PW 2.5 two weeks ago and all seemed to be working well then. Double check that you've got the latest version. Though based on your follow-up info, it sounds like maybe there is some issue with this module. Though I haven't observed it in my testing here yet.

Code before talk. With 2.5.0 released Friday, and 2.5.1 dev released today, there's been a lot of code.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

Wow–I'm speechless. This is truly amazing blad. You've got some serious video editing skills. Thank you, this really made my day!

This module may get put into the core. Not sure yet. But it does seem like something that may be useful to most PW installs, so seriously considering it once it's fully refined and has a few miles on it, etc. No need to worry – if you click it, the next screen tells you that it is a downgrade. Though it's perfectly fine to downgrade or upgrade between master and dev, unless using something that's only in dev. I've been doing it all week. This is consistent with how PW currently renders all system notices: at superuser login. If it's an error, it shows up red. Otherwise it shows up green. Upgrades to core or modules in PW aren't particularly important most of the time (since it isn't WordPress). It's more just an "FYI", "if you are looking for it" kind of thing. The info is always available in Setup > Upgrades. But I hear what you are saying and you aren't the first to say they tune out PW's green messages. Antti and I are working on a new notifications system and I expect we're going to do some great things there. This module will be one of a few we use to test the new notifications system. But until then I thought it best to keep consistent with the way PW currently does things with regard to system notices. So just wanted to mention there are some nice new things coming here, but for the overall system rather than just 1 module.

Some upgrades to the upgrade module. It now scans for module upgrades too, and provides notifications of upgrades that show up when superuser logs in: Main screen: Login notifications: Note that you have to have the latest PW (2.4.19 or hopefully 2.5 later today) in order to use the modules upgrades or login notifications. The core upgrades portion will work with old PW versions. Also the screenshot says it's called "Core Upgrade", but that's because I already had it installed. If you install it anew now, it's simply called "Upgrades".

Totoff there is version 0.2.3b, see the FormBuilder board (let me know if you don't see it). I'm planning to release 0.2.5, which is based on 0.2.3b, once PW 2.5 is out.

Totoff, there's no expiration on the keys. They will definitely still work with 2.5 and beyond.

When I took those screenshots, I was basically left with no more sites to upgrade.

We're aiming for soft launch this Friday and official a week later. Tried for last Friday but still had some issues to resolve + waiting on some things. I believe it's safe to start using now, but you'll still want to upgrade when 2.5 is official.

Thanks for testing it out Joss and Adrian. I've updated the phrases with your language Joss. Adrian, I'm guessing your PHP timed out. I meant to have a set_time_limit in there to prevent that, but didn't have it there yet. It's now there. As for download time, it's taking between 2-3 seconds here, server-to-server, and I'm thinking that's likely typical for web servers which is more the intended environment for this tool. But if more people are finding the download slow, we can definitely look further at things like progress bars or some kind of dancing icons or something

I've been working on a module to make it really simple to upgrade ProcessWire from one version to another. Especially as a way to make it easy to upgrade from PW 2.4 to 2.5, or to upgrade from one dev version to another. This tool supports upgrading between any branches of ProcessWire (currently we only have master and dev on GitHub). It will also let you downgrade your ProcessWire version, though no reason to do that. The module keeps up-to-date directly with GitHub, so it works as a long-term tool for every upgrade if you want it to. It works best if your file system is writable. However, if it isn't, the tool can still be used. It will still download the upgrade files to the server and then tell you where to move them. I should also mention that this module is somewhat inspired by a similar module Nico built awhile back called AutoUpgrade. So far I've used this tool to upgrade this site (processwire.com), the skyscrapers site, and the modules site (modules.processwire.com). Before releasing this officially in the modules directory, or suggesting it for production use, I'd like to get some help testing. If anyone has availability to help test this on non-production sites, your help is appreciated. It can be downloaded from GitHub here. As a bonus, it will also be a good opportunity to help test PW 2.5! Thanks in advance. What I'd really like to do as the next step with this is make it support upgrade by FTP. That would provide a nicer and safer solution for those that don't have writable file systems on their servers. This tool should be compatible with ProcessWire versions as far back as 2.3.4. I will also update it to support older versions than that if there's demand for it.

Pierre-Luc it's nice of you to ask, but also unnecessary. That's always your choice if you want to release something you've created. There aren't any restrictions on what can be released as free modules (so long as they don't use code from commercial ones).

xorotle, I've not been able to duplicate this, though have tried a couple of times now. As far as I can tell, CropImage is working well with the latest dev version (2.4.18). What version of PW are you using? The line numbers you indicated don't line up with more recent versions of InputfieldFile. So I'm wondering if you might be able to solve this one by upgrading to a newer ProcessWire. Also double check that you've got the latest CropImage as well.

Good points from Horst. On my sites I just replace the /wire/ directory with the new one. Actually I rename the old one to ".wire" (or something like that, just in case I need it back… never have though) then put in the new one. PW automatically takes care of any database changes, so you don't need to worry about that. Also, if it needs an .htaccess or index.php update, PW will tell you the next time you login to the admin superuser account. So I wouldn't worry about replacing anything but /wire/ unless PW starts harassing you about it. The htaccess change Horst found above only matters for the installer, which isn't applicable on a site upgrade.

So long as the field isn't a repeater, file/image, or PageTable, PW 2.5 (2.4 dev) can do it in one query, which should take about a second. PW 2.4 and prior cycled through each page to delete a field. So that could be a slow process, though it is a good process. PW 2.5 still has to cycle through every file/image or repeater/pagetable field since they all involve external assets that also need to be deleted. But if the field you need to delete isn't one of those, you may want to consider waiting for PW 2.5 since we may soft launch it as soon as next week. Or you could try out the dev branch locally to test things out and see if you want to use it live.

If you turn off ACF and turn off HTML Purifier, you've essentially got what we had with TinyMCE. I grew increasingly uncomfortable with TinyMCE as ProcessWire has grown. The fact that it is open with regard to what markup it will allow also creates quality problems for a site especially over time. But an even bigger issue is security. An RTE without a strong filter behind it is a security hole because markup from RTEs is already entity encoded and ready for output. If a user with access to the RTE knows what they are doing, they can manipulate the POST request to the server, adding in some of their own markup (and XSS). This is particularly easy to do with TinyMCE. And once you can do that, you can get very creative indeed. A non-superuser with page edit access using TinyMCE could feasibly insert a script to make a front-end page render like a PW admin login screen. The next time the superuser views that page on autopilot, they type in their password and then the system is compromised. So CKEditor + HTML Purifier prevents that problem. ACF doesn't prevent that problem, but goes a long ways towards solving the other major RTE issue: markup quality and preventing markup degradation. You can turn those filters off, but it's important to understand the compromises that result. If your admin is limited to yourself or just superusers then you probably have no need for HTML purifier. But I sleep a lot better at night knowing we have a secure solution for the RTE. Since CKEditor can be configured to be as open-ended as TinyMCE (even if we don't recommend it for anyone but superusers), I don't necessarily see any reason to use TinyMCE any more... we now have a stronger feature set and much nicer plugin system for CKEditor than we ever had for TinyMCE. But I'll still be maintaining and supporting TinyMCE as a 3rd party module for a long time to come. On most of the sites where I'm already using TinyMCE, I'm likely to keep using it. But for any new installations CKEditor is definitely the way to go.

Some more updates on the multi-language front: ProcessWire now comes with a multi-language site profile Language translation files now split by site and core These are the last two things I'd wanted to add to PW 2.5 before release, so please consider it now in release candidate stage. Your help testing is appreciated and please us know if you run into anything that's not working. PW is already designed for such a feature and has been since the beginning. Development of PW2's core and development of PW1's draft system had overlapping timelines. I had planned on including drafts of published pages in PW2 until I saw how little use they got among my clients at the time. In PW2, page IDs 500-900 are reserved and recyclable/reusable for drafts, and there are already methods in the core and Fieldtypes that are there to aid in managing drafts. PW's unpublished vs. published pages system already accommodates the biggest needs in drafts. Drafts and unpublished pages are essentially the same thing in the minds of most (of my clients at least). The drafts that you are talking about are something different and really only useful in situations where you've got pages on a site that continue to undergo major changes after they've already been published. Since developing the drafts system in PW1, I've learned that most don't publish content that way. Instead, they work on something, publish it when they are ready, then move onto the next thing. Though drafts for published pages are definitely useful when/if that is the need, and I have no doubt that some clients have the need. But the reality is that it's a whole lot of overhead for something that most won't ever use. As a result, it would likely come in the form of a module (whether uninstalled core, or 3rd party I'm not sure). But it's definitely coming. In terms of technical challenges for drafts of already published pages, they are only with regard to Fieldtypes that create other pages. Specifically: Repeaters and PageTable. Those two Fieldtypes are the only two I'm aware of that don't currently support drafts for already published pages (though it's possible they could with modifications). All the other Fieldtypes are pretty much draft-ready. Technically there is significant overhead associated with drafts of published pages. It's a 2nd set of editable data. However, you wouldn't feel the effect of it unless creating or publishing a draft, and specially one that had a large amount of assets connected with it. As a result, most would likely not feel the overhead. In terms of comparing overhead, repeaters have more overhead than drafts. I'm very much sold on Teppo's versioning system, and I use it on pretty much everything now. While I have plans to finish the drafts system that's already started, I don't have plans to reinvent what Teppo has already done with regard to versioning. If people have more needs in terms of versioning, we should probably talk to Teppo.

Sparrow, assuming you upgraded the .htaccess file with the PW version, I would start by renaming the .htaccess file to htaccess.txt and then try to reload the homepage. Is the internal server error gone? If so, then restore the .htaccess and start commenting stuff out to determine which htaccess rule is causing the issue. If that's not the issue, then next look at your PHP and MySQL versions: what versions are they? You'll want to get more info on the error message. Start by editing /site/config.php and enabling $config->debug=true; on the line where it's currently turned off. Reload, do you see any more detail about the error? Check /site/assets/logs/errors.txt, anything there? Look for PHP's main error log to see what it has to say. On some servers this can be hard to find, so you may have to examine the phpinfo(); result to determine the location.