ryan

I'm not really sure of the source of the issue here, but can answer some things about the original error you received here. Page::statusCorrupted means that some code modified the value of a page field when output formatting was ON. That means that the page is in a state where saving it could cause data corruption (like saving formatted data to the DB). The way to prevent this error is to ensure that output formatting is OFF before you retrieve and populate back any values to the $page that will be saved. You can turn off output formatting via $page->setOutputFormatting(false); or just: $page->of(false); If we look at the code where the error originated, it's a bit unusual because output formatting is being turned off before the save(); I would look in code unrelated to and above your comments code to see if you are setting any field values to the page. Given that the page has statusCorrupted and we can clearly see $page->setOutputFormatting(false); that means that the page had already been corrupted before your comments were even rendered. Meaning, I think there is a good chance this is not related to comments at all. Check what's in your own code (any $page->set(key,value) or $page->field = "value" anywhere?) and if you don't see anything there let us know what 3rd party modules are installed.

The only time you'd want to make the password field required is when using it for a new user form or something like that. Otherwise, I'd suggest not making it a required field unless you want people to change their password every time. I'm not positive about what your context is in this case, but because the built-in password field is designed for a very specific purpose, you might just want to use your own markup for a password field. Or, if using an InputfieldForm, you can use InputfieldText and change the type attribute to 'password': $pass = $modules->get('InputfieldText'); $pass->attr('type', 'password'); $pass->attr('name', 'pass'); $pass->label = 'Your password'; $pass->required = (bool) whateverConditionYouWant();

Beautiful work @jlahijani! Great job with the screencast too–I need to hire you to do my screencasts. Unless you've got other plans to produce it into an SAAS app or something, you should definitely release it. I think a lot of people would find this very useful both as a great tool to use and an impressive example to learn from.

If the users are all editors, it's true that you won't want to use any automatic caching (and may not be able to). But you can always use MarkupCache to cache elements that you know are ok to do so. In your case, I would try to isolate the bottleneck. Wrap statements like this around your significant sections of code, until you track down what is causing the slowdown: $timer = Debug::timer(); // .. a block of code you want to measure $this->message(Debug::timer($timer)); It'll tell you how many seconds the block took to execute. If this is outside of admin context, you can replace the $this->message() with an echo or something else, anywhere that you can see the results. Once you find the source of the bottleneck(s), you may be able to optimize them to improve the speed. Often times there is just an inefficient block of code that can be fixed. But if that's not the case, you may want to then look at MarkupCache'ing them. $cache = $modules->get('MarkupCache'); $out = $cache->get('your-unique-name', 86400); // 86400=num seconds age if(!$out) { $out = SomethingThatTakesAwhile(); $cache->save($out); } echo $out; I don't know about that context, but an opcode cache can be very helpful. If you can't use an opcode cache, I would make whatever changes are necessary so that you can. No PHP 5.4+ should not break anything. In fact, I think you'll find that just switching to PHP 5.4 provides a nice speed boost in itself (at least it seemed like it to me). I am running PHP 5.4+ on all of my own PW installs now.

@underk, thanks for your interest in contributing here. If you'd like to work on the French translation, I'd encourage you to fork it, or download it, and post a link to your updated repo or ZIP.

Thanks Horst! Your knowledge and code for working with images is fantastic! I will pull this into dev soon. I need to get caught up with my forum messages, and then hoping to catch up with my GitHub messages next week. Separate PR is fine. For stuff like this, I generally make sure I understand everything that gets committed by re-typing the lines myself or at least going through them individually on a copy/paste, until I understand it in full. It takes longer to do this way, but it ensures I can properly support it in the future if a question comes up and you are on vacation.

Is your map field in a tab other than "content"? This is the same as having the map field collapsed. The Map needs to appear on the main "content" tab. I'm not really sure why, but Google Maps doesn't like being hidden when the page renders. There is not supposed to be a map on the screenshot you posted. I'm not sure if that's where you are looking for one to appear, but wanted to mention it just in case. Where you will see a map is in your page editor.

I've not attempted to modify the SCSS files or anything like that. The Foundation that comes with this profile is just a stock version of it, directly from their ZIP file. To update it, you simply replace the /site/templates/foundation/ directory with a newer one downloaded from their site.

I've just updated the profile exporter module to display a note about the incompatibility when it detects the multli-language page names or fields modules installed.

The issue with the profile export is just that the profile exporter was built before multi-language support was, so it doesn't know about it. It's on my to-do list to update it. But since you are using multi-language, I would take the profile exporter out of the equation here and try to do your export/import with PhpMyAdmin (or another mysql client) instead. I'm not positive, but wasn't MySQL 5.0.8 the one with the sort bug? Otherwise, I'm not aware of any issues with that version of MySQL. Technically, PW can actually use later versions of MySQL 4 too, even if we don't document that.

Adrian, it looks to me like you've done a beautiful job coding and documenting this module–nice work! I really like what I see here. I had once starting building a phone Fieldtype and gave up after discovering the crazy number of formats out there. So lots of respect to you for sticking with it and producing something complete and very well done here. Here are my only suggestions (minor): It might be nice to add a __toString() method to your Phone class, so when someone does "echo $page->phone"; they get a formatted (default) string. I'm thinking the country and extension inputs may not be applicable to all potential users–maybe there could be a way to turn them off? Related to input again, it's a little unusual (in my locale) to split out the components of phone numbers into separate fields. Though the coder side of me likes that you've done that here. But wonder if there might be some alternate input option that lets you populate it in one field and have a processInput that separates it out into the parts with a preg_split('/[^\d]/', $phone) or something.

The module's getCompatibleFieldtypes() function returns a blank array, meaning it's not compatible with any other fieldtypes (for the purpose of changing type). I did just test to be sure, but it doesn't let me change the type of a concat field. But then I tried to change an existing text field to a concat–now I see the issue. Ideally, it wouldn't let you convert an existing text field to a concat field. I'll have to think a little more on the best way to prevent that. I may have to modify the concat fieldtype to stop extending FieldtypeText.

It sounds like you might be running a version of ProcessWire prior to 2.3? It doesn't look to me like this jQuery multiselect plugin comes with any sort of pagination capabilities. I'm not really sure how they would do it, so kind of doubt that's on their roadmap, but will keep an eye out. At the moment, I don't plan to include this module in the core. Though if it's something that we find people will use on more than 30% of sites, then it would be something to consider. Okay I see what you mean there. Those two modules assume the "parent_id" to mean just the starting point (rather than both starting & ending point), which is why they are called out separately. I didn't think there's be much use for that feature beyond those two modules, but glad to hear I'm wrong–I'm sure I can find some other way to make that configurable.

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

I haven't had enough bandwidth to give it enough testing to commit to dev just yet, but attached are the changes I implemented earlier this week in an attempt to fix these issues. I don't yet know if they actually fix them or not. But if you have a chance to test it out, please let me know what you find. LanguageSupportPageNames.module

This design direction is really looking good. It's as good of a replacement for the default admin theme that I've seen, and I think it could be a good direction for us. I agree with Antti, that I liked the reduction of the borders from the latest version. I did kind of prefer the icons in the page list actions, though am thinking it might be good to just have 3 configurable options there: text only, icons+text, or icons only. I think that the screenshots do demonstrate that a sidebar page-list is workable with condensed indents–it actually looks pretty great. But I'm not convinced it's workable on the technical side–I think we'd have to go with frames in order to avoid having to re-render that page-list on every edit. And even then, we run into issues, like when and how to refresh it automatically (like when a title is change for instance). Though I'm sure it's all solvable one way or another, and I think we should give it a chance and see where it takes us. Other elements that I think would be useful would be things that Soma has already done with his Teflon theme. One example I can think of is the drop downs that let you go straight to a template or field. I know the concepts shown here don't get down to that level of granularity yet, so just mentioning things I've liked. I know some people like the current minimal admin theme, and I am one of them (I can't seem to use anything else for more than a few minutes). But the default admin theme has to be one that markets us well, and apparently the current one does not have the broad appeal it needs to have. If there's one thing that comes up more than any other when people are checking out ProcessWire for the first time, it's a general aversion to the admin theme. This has been the case since the beginning. I don't understand it, but I think the current admin theme is the only thing preventing wider adoption of ProcessWire. There's a large segment of users out there that judge a product on how it appears to their subjective design sense, and they don't bother looking further if the admin look doesn't excite them. So what we need is something that draws people in rather than halts them from looking further. That's not to say that the current admin theme is bad (I quite like it myself), but that the current admin theme must be an acquired taste–something probably better as a 3rd party theme option rather than the default one. Diogo and I may keep using the current admin theme, but the time has come where we need a different default theme to increase our user base. There are several other admin themes that already exist that could accomplish this already. But like has been mentioned above (and by others before) there is also a need to optimize and improve some of the framework elements behind it all. So building a new default admin theme is best done with a little bit larger scope of changes than would usually accompany an admin theme. I'm not interested in switching away from jQuery UI, but would support inclusion of another minimal framework to provide more foundation both to grid and typography–the things that jQuery UI doesn't do, and isn't designed to do. I'm not sure what framework would be right, or if homebrewing would be better. Regardless, if we were to start developing a new default admin theme from scratch, I think Philip's design here is a good direction to build from. I don't have the bandwidth to get involved with this anytime particularly soon, but it should maybe be a top priority after release of ProcessWire 2.4.

I've committed an update that I think should fix this–please let me know if you still experience it. I wasn't able to duplicate exactly what you are talking about, but it was more just a matter of available time, and think I knew what the issue was. Just looking for confirmation that I fixed the right thing, but definitely found an issue that needed fixing either way. I'm not sure I understand the question/comment/request? I think it probably depends on the situation. But there are likely several scenarios that won't work when it comes to repeaters, because repeaters manipulate the field names behind the scenes, and both the definition of dependencies as well as the JS require the original field names to be in tact.

Your best bet is to use the API directly rather than trying to go it alone with the DB driver. Though the dev branch (and upcoming PW 2.4) use the PDO driver and you could certainly manage your own transactions in there if you wanted to. But I'm not sure you need transactions to accomplish this. I'm also not sure what sort of fatal error you are expecting may occur during the creation of your tree? But if the data in the JSON has non-unique page names with the same parent or something, then it's certainly possible. So one route you could take would be to build your tree within a try/catch and if an exception occurs during the process of building your tree, have your catch call $pages->delete($rootPage, true); to perform a recursive delete on everything that was created. Another strategy could be to just make everything (or just your $rootPage) unpublished during creation, and published upon success.

This one is tough for me to debug just because my access to IE is limited (I have no Windows PCs in my office). I also have a deep-seated IE-aversion, so usually need to be pestered a bit to use it. I'll ask my wife to bring her computer from her office, which does have IE (though IE10 I think).

Probably not. The URL itself would still have to be compliant with the standard URL character set, but the filename itself that appears on the user's computer could be different.

For efficiency reasons, Textformatter modules run from a single instance, so I'm guessing this is a side effect of that. I'll look into options for how we might get around the issue the next time I'm making updates to it. But assuming that 'body' is a rich text field and Hanna Code is the only Textformatter you had on it, you could probably get the unformatted version of it from your Hanna code and use that instead, to avoid triggering the circular reference (or whatever it's called). echo $child->getUnformatted('body');

I'm not sure about exactly what's causing it, except that I ran into it too at one time and fixed it on the dev branch. You can make the same change I did outlined in this thread or you can switch to the dev branch. Hopefully either should fix it.

Thanks, it looks like I've got a few more updates to make! Actually just checked, and it looks like I've already made them but just not committed them. Though a couple of those are actually just commented out versions of live() that have already been replaced. I keep the old commented version just because I find live() easier to read and comprehend what's going on. I'll go ahead and commit the rest here shortly. I'm running jQuery 2.x locally, with the migration plugin. I plan to include the latest 2.x jQuery with PW 2.4. I haven't yet found any others, though that might be because I'm still using the migration plugin to identify stuff that needs updating. But I'm not married to the fancybox plugin–we'll replace it with something else.

Nice work Horst!

Assuming this is what I think it is, see the fix in this post. I'm not exactly sure why this error appears in some instances, but if you apply that change (or switch to the dev branch) that will hopefully fix it.