ryan

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.

Save process: $page->fieldName = 'value'; sends 'value' to Fieldtype::sanitizeValue(); and then sanitized value is kept with $page. $pages->save($page); calls Fieldtype::savePageField() for each field on the page that changed. Numbers 3 and 4 below repeat for each of these calls. Fieldtype::savePageField() calls Fieldtype::sleepValue() to return value as basic type for storage. If value is something simple like an integer or string, then sleepValue may not need to do anything at all. Fieldtype::savePageField() saves the "sleeping" value to DB. Load process: Access to $page->fieldName (i.e. $page->title) calls Page::getFieldValue(). Page::getFieldValue() calls Fieldtype::loadPageField() to load value from DB (if not previously loaded). After Fieldtype::loadPageField() loads value from DB, it calls Fieldtype::wakeupValue() to convert value from basic storage type to runtime type (i.e. array to object). If value is something simple like an integer or string, wakeupValue may not need to do anything at all. The "awake" value gets returned to Page::getFieldValue(). With this value hand, Page::getFieldValue() remembers the value so it doesn't have to pull from DB again. If $page->outputFormatting is TRUE, Page::getFieldValue() runs the value through Fieldtype::formatValue(). That modifies the value for runtime output (example: applying an entity encoder to a text value). In the case of text fields, this would be when the value is routed through Textformatter modules. Note that formatValue() is called on every access to $page->fieldName, as PW only keeps the unformatted value in memory. Page::getFieldValue() returns the value, which you see as the result of your $page->fieldName call. Note that when you get a $page object, the fields aren't actually loaded until you try to access them. Meaning the above process occurs upon field access, not at page load. However, if the field has the "autojoin" option checked, then the above process is very different. However, those differences don't matter to any Fieldtype code (or any other code I can think of). As for error handing, this would typically be done in the Inputfield module, most commonly at Inputfield::processInput or in some cases Inputfield::setAttribute('value', 'my value'). However, it is also okay to trigger errors from Fieldtype::sanitizeValue, but just note that that method will be called on values regardless of whether they came from the API, user input or from the DB. Meaning, time consuming validations are best performed at the input (Inputfield) stage. This sounds a lot like a Textformatter module. If that's your need, then your job is simple and you don't have to worry about any hooks or anything other than making a Textformatter module with Textformatter::format($value) or the newer Textformatter::formatValue($page, $field, $value). More likely you just want FieldtypeTextarea::wakeupValue, as that should be called for both instances above (FieldtypeTextareaLanguage extends FieldtypeTextarea). Most likely you are getting double calls having the two above hooks.

@Jan Romero: What version of PHP and MySQL are you running? You also mentioned 3rd party modules–which modules? (If not Textareas ProField?). The ProFields have been developed in tandem with the dev branch, so I'm fairly sure that wouldn't be it. But the commit you indicated did change the way module information is cached. I found one other instance of a similar upgrade error and we traced it to a bug in a specific PHP Version. That's why I'm curious about the versions of software you are running. I think this is largely the inclusion of CKEditor. The Iridium profile does take up some space since it has a lot of photos, so I may leave that one as an external install. Overall though, I think we're being pretty safe with file size. I can still download a ZIP from GitHub in less than 3 seconds, and we've never had any complaints that file size was preventing someone from trying or using PW. As a result, I think we're better off using file space where we can to make sure PW really impresses people when they download and try it out. On the other hand, we should also be safe and not include multiple RTEs, etc. For example, we removed TinyMCE when we bundled in CKEditor. There has been little demand for this, that's why it keeps getting pushed back. How many threads do you see posted of people asking for this capability? I agree it's a nice capability, and I would like it too. But I try and focus my efforts on what will get used the most. At least the non-sponsored new additions you see in 2.5 are largely based on what's been asked for repeatedly in the forums (as well as what I would personally find useful). So we'll count your request here as momentum for drafts. The funny thing is that PW1 had full drafts capability, had a huge amount of work behind it, and it worked well. The unfunny thing is that clients rarely used it. The primary time that clients (my clients at least) wanted a draft of something was when creating a page. That's why we've already got that in PW2. I ended up feeling that all the work behind drafts in PW1 was kind of a waste of time. Of course the PW2 user base is much larger and the potential audience for such a feature is much larger now. I personally would like to have drafts for already published pages too, but the reality is there's only a small segment that will actually take advantage of it. It's a feature that sounds good, but few use. Still, we may have the critical mass now for it to be worthwhile. And it's also on the checklist of many, even if they won't use it. I even have it mostly built already, and have been occasionally working on it, but it's been kept in the background as more popular features have gotten attention. I appreciate the interest of course, but I don't think this is necessary. We've already got commercial modules funding developing of ProcessWire. The focus on what gets added is also largely based on what are the most common needs people have around here, within the limits of feasibility and schedule.

That modules issue mentioned above should be fixed now, though let me know if you still experience it. A few interesting mid-week updates for those following ProcessWire 2.5 development (aka the dev branch). Here are links to the blog post about it: The ProcessWire installer now lets you choose a site profile New site profile exporter is far better than the previous Support for append/prepend files on a per-template basis With ProcessWire 2.5 getting very close to release, we could especially use help testing out the new installer if anyone wants to give it a try.

I might not be totally understanding the scenario, but if a child can't be deleted then the parent definitely can't be deleted either. Otherwise, you'd end up with orphaned pages in the DB. So there wouldn't be much purpose in issuing a warning or doing anything other than halting immediately. Something that would result in orphaned pages in the DB should be a fatal error, at least in my opinion.

I can't seem to duplicate this one. Can anyone else? I have a few work-in-progress files I've not yet committed, and don't think they should affect this, but that's my best guess. Can someone else confirm they are seeing "required: 1" regardless of the field's required state? Properties that begin with an underscore, like _dateInputFormat are for runtime use only. Previously it would blindly accept those. Now it remembers not to save them in the DB. I'll update the export function to exclude them as well. But since the property shouldn't be there in the first place, go to Fields > act_start_date > Alert. Check the box to delete that property and Save. Though if you don't see it listed as a property, you might also be able to solve this just by going to the field and saving it without doing anything else.

Hani, are you able to update this module listing to point to a GitHub repo of this project? With the module installation options in the PW modules menu, the current linked file (a .module file) doesn't work for automatic installation. While a GitHub repo is preferable, it may work if you can ZIP the module into an archive and post that instead. In either case, we need to update your module listing so that it points to GitHub and/or your module repo. Let me know if I can assist.

SiNNuT, glad you are liking this tool. I just committed an update that should fix this (I had an array_merge() with the wrong order of arguments). Actually, I was getting required as always empty (even if it was required) so the behavior I saw was a little different than what you mentioned. Can you confirm it fixes the issue?

Alejandro, any idea how you were able to install ProcessLanguage before LanguageSupport? I've been here trying to figure out how that might have happened, but I can't find any paths that let me do it. Even the API will halt the operation. Clearly there must be some path to do it though, as otherwise I don't think you could have gotten that error. I don't have an install button for ProcessLanguage either (that doesn't appear until the dependencies are met). Adrian it sounds like you might have clicked on the module title, as there's no Install button present. A default javascript action will still pop-up if you click on it, but it's got nothing to do since there is no install button. If there's any confusion coming from that, I think we'll just drop that javascript action, as I don't think it's even translatable at present... and it's not had much purpose ever since we moved install has been a separate button.

Wayne, thanks I think you've done a good job of outlining the issue. Before we attempt to fix it by requiring a re-translation of existing terms, I thought we might try to solve it by making the order of terms translatable. Could you (or anyone else that wants to try) try replacing this line in /wire/core/Functions.php: return sprintf('%s%d%s%s %s', $prepend, (int) $difference, $space, $period, $tense); // i.e. 2 days ago (d=qty, 2=period, 3=tense) With these lines: $quantity = $prepend . $difference . $space; $format = __('Q P T', __FILE__); // Relative time order: Q=Quantity, P=Period, T=Tense (i.e. 2 Days Ago) $out = str_replace(array('Q', 'P', 'T'), array(" $quantity", " $period", " $tense"), $format); if($abbreviate === 1) $out = str_replace("$quantity $period", "$quantity$period", $out); return trim($out); Then translate the /wire/core/Functions.php using the Setup > Languages > Translation tool, and adjust the order of Q, P, and T in the translation engine according to what makes sense with the locality. For instance, it German it sounds like it should be: T Q P. I'm curious if this solution resolves the issue or if further changes might be necessary. Thanks.

Raymond, Can you try out the update I just pushed to FieldtypeConcat? I couldn't duplicate the issue you are seeing, but I can how why it's feasible to occur. I updated the module to identify it's requirements for ProcessWire 2.5+ dependencies and am wondering if this might resolve the issue.

Child pages don't become part of the PageTable unless they are added from the PageTable field. It is possible for a parent to contain multiple children, some PageTable some unrelated. So just adding a child to a parent does not automatically add it to a PageTable (not currently anyway). The relations are tracked with a separate table rather than with a parent/child relationship.

This is possible. Try the cmscritic example. Click like on ProcessWire. You should see a "products you liked" link on the top right corner of directory list pages. If you'd like I can send you the readme file which has instructions on how to implement.

The configuration as it applies to Fieldtype or Inputfield modules is exported/imported. If you are talking about other modules (like the configuration that's in Admin > Modules > Site or Core), then it's certainly feasible to do it the same way. Something to consider for the future.

Soma, thanks for testing it out. I'm guessing there are a few Fieldtypes it's not going to work with yet (I've tested most, but not yet all). This whole system should be considered alpha at this stage, so the usual disclaimer applies: use it for play rather than production. In the case of the error message you got there, it looks like FIeldtypeCache has a bug where its attempting to access its DB table before the field exists. I think this is something that has to be fixed in FieldtyepCache rather than import/export. But I would like the export/import to capture those kinds of exceptions, so this'll be a good one to test with while I fix it.

In case anyone is interested in trying out some of the things I was talking about in previous posts here, the latest dev branch has a field import/export function. You'll see it in the lower right corner of Setup > Fields. It enables you to copy and paste any fields across any PW installations. Locally, I also have this working for templates (with fieldgroups), though that part needs a little more work so it's not yet committed. I also have fields, templates and fieldgroups mirroring every change to JSON files, as an option that can be enabled for those that want to version these things with Git and what not. That part also isn't yet committed to dev, but will be soon. However, I figured the copy/paste function probably had the largest use potential. It makes migrating field changes (or creation of new fields) quite a simple task. Next up on the commits will be the same thing for templates (with fieldgroups). (note I didn't take these screenshots together, so they aren't referencing the same fields).

We can take criticism here, it's always helpful. It's true that 30 minutes really isn't enough to understand or evaluate ProcessWire, but I do like hearing the 30 minute perspective because I can see that is something we need to work on. While I think our audience is currently a bit different than WordPress, WP is the largest CMS platform by far and so we always have to pay attention as to how we're perceived by the WordPress community. I would like that perception to be one where people that enjoy WordPress would consider ProcessWire when they have needs to develop something beyond what WordPress specializes in. Not that WordPress couldn't handle it (it's powering some quite large and comprehensive sites) but that ProcessWire can accommodate more custom, complex and larger sites quite a bit more easily and efficiently, at least once you know ProcessWire. WP and PW are both useful tools for any developer to keep in their pocket. While you can develop quite a nice blog in PW, you may save yourself time to do it in WP. Likewise, you can develop quite large and complex sites in WP, but you would save your save quite a bit of time to do it in PW instead. That's an oversimplification of differences, but just saying that these tools aren't mutually exclusive. We're both on the LAMP and GNU teams too. As a side note, ProcessWire is here in part because of WordPress, or at least the founder. I didn't even know about WordPress at the time (beyond hearing it was something like Moveable Type), but was really inspired by Matt Mullenweg's speech at SXSW (I think it was 2006, it's been a few years), and that led me into open source. The way he spoke about open source struck a chord. We exchanged a couple of emails afterwards and I thanked him and told him I was going to develop ProcessWire as an open source project because his speech was such an inspiration. Prior to that it had been in development, but as a closed source project. It took more than 4 years and 2-rewrites before it was released, but that's where PW started as an open source project.