ryan

You should be able to use this module from the API side like you've mentioned. The module is built around a jQuery UI plugin called uix.multiselect, so you'll want to make sure that your context includes jQuery UI. Like with all of the selection inputfields, you'll have to add some selectable options: // add some options $test->addOption('a', 'Option A'); $test->addOption('b', 'Option B'); $test->addOption('c', 'Option C'); // now tell it which ones are already selected $test->attr('value', array('a', 'c'));

It sounds like you already solved this, but I just wanted to mention that the "link" option in CKEditor is the way you link to files on your page. When you highlight some text and click the link icon, you'll have a choice of linking to a URL or a file. It'll give you a select box of files attached to your page. If you want to link to a file attached to another page, you can click the link to select another page from within the modal window.

What other modules use fancybox? I'm not planning to remove it from the source completely, at least not till 3.0. So if some other module needs to use it, it'll still be there–we can simply add an extra $config->scripts->add('jquery migration plugin') to the top of the JqueryFancybox.module file, and it should continue to work even with the new version of jQuery installed. But ideally I want to switch to a different, more mobile friendly lightbox for our InputfieldImage to use.

Thanks for your help debugging this Soma. Did this issue seem to be introduced or worsened by the LanguageSupportPageNames.module that I posted earlier? I'm having to leave the house right now so can't look closer at the moment, but need setup an environment where I can repeat it and then fix it.

As a side note, I just wanted to mention that you wouldn't want to use dirname() in a URL like that, as it's giving you a server path, not a URL. Secondly, if you were using dirname(__FILE__); somewhere else, remember that its output does not include a trailing slash like ProcessWire's paths do. So you'd have to add a trailing slash to it's output.

I think that it is okay to use InnoDB with ProcessWire though. At least, I seem to recall one person here had converted to it without issue. When ProcessWire was originally being developed, InnoDB did not support fulltext indexes, but apparently it does now.

You can always use a try { ... } catch(Exception $e) { ... } but I think it's probably better to leave that as a fatal condition and stop processing.

That's mostly correct, if running from root, there shouldn't be anything to show except for a single slash "/".

I would guess that wireEncodeJSON() is converting your string value to an integer. It will do this if the value matches ctype_digit("$value"); That means a value like "0888" would get converted to an integer of 888. But a value of "0888 1234" would not, as it contains a space. In your case, I'd stick with the regular json_encode(). wireEncodeJSON() was made for saving module and field configuration settings, where we wanted to remove settings that had blank values in the name of space savings. If you also want that capability, but wireEncodeJSON() doesn't do it exactly how you want, you may want to copy the function out of /wire/core/Functions.php and into your own (named differently) in /site/templates/includes/functions.php (or something like that). You probably want to make adjustments to the line that converts it to an integer.

If you get a 302, my guess is that you are accessing a URL with another RewriteRule behind it. For instance, if you are enforcing trailing slashes via an .htaccess file, and you access a URL without trailing slashes, then Apache will first redirect to the same URL with a slash (which could be a 302), and the resulting page will have a 404.

I did change this before, but had to change it back as I later found it broke something else. It's been awhile now and I don't even remember what it was that was broken. One way you can get around it is to change the 'process' field on the admin homepage to your own. ProcessHome is a very simple module, so you can just copy it to your /site/modules/ProcessHomeCustom.module and change it to do what you need, then edit the admin page and make it use your version.

I'm not sure that there is, as TinyMCE is running in its own iframe. Maybe it is possible to add stuff to that iframe, but not that I'm aware of. If I had your need, I would probably use the InputfieldCKEditor module in Inline mode instead, as that should be a lot simpler to control. Lately I prefer using it for all my textareas over TinyMCE.

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.