ryan

Yes, there should be a placeholder option for any text-based field in ProcessWire. You'll see it when configuring it. To use it from the API side, you'd do: $inputfield->attr('placeholder', 'your placeholder text');

Nice job Soma. I've actually had the same issue with TinyMCE and I don't even use templates. When using the <pre> format, if it's the last thing in the document, there's no way to add something after it. For example, if I'm editing the processwire.com site and adding a code example, suddenly I can't continue with anything after that. So I have to open up the HTML modal and add a <p>...</p> manually. It sounds like your plugin would fix this issue too.

I don't want to say anything that implies we aren't moving forward. The worst thing for software is to be stuck in time. But I do believe our API is a constant that will transcend versions. In fact, the term API implies a level of consistency and predictability that I take seriously. If for some reason we need to change parts of the API in order to move forward in the future, then we would version it. Meaning, you'd still get the old behavior if your $config->apiVersion was not up-to-date. Though I've not yet seen any reason for API changes, just additions. Believe me I don't want to create upgrade hassles for myself or anyone else, though I don't typically upgrade existing PW installs unless the client needs something from the newer version. Libraries like jQuery can't afford to version their API because they have to be as tiny as possible. But we can afford to do that, because source code size is far less of an issue for a server side application than a client side one. But this is all theoretical, as I mentioned we have not yet come across any reason to change the API. I agree with Pete.

Hani, ProcessWire will scale pretty infinitely in terms of pages, but not in terms of fields or templates. The same can be said of databases in general–you can have millions of rows in a table, but probably don't want millions of tables. I would say you've gone beyond what may be practical for long term use and maintenance of the site. At least, I have never tested ProcessWire with any more than 200 fields (and I thought that was an insane amount). I would be curious why so many fields are necessary? It might be good for us to get a list of all the fields, which may lead to some good suggestions on alternatives. But this is a situation where I think you might really benefit from making your own Fieldtype and Inputfield combinations. It is surprisingly simple to do, and can represent any DB table, no matter how many columns it needs. There is far less overhead in having a custom Fieldtype that represents a table with 100 columns, than there is in having 100 separate fields. Have a look at Adrian's new FieldtypePhone/InputfieldPhone module for a good example of how to represent a DB table with a Fieldtype. Some other options I can think of relate to ProFields, a pack of modules I've been working on to release soon (probably as commercially supported like FormBuilder and ProCache). It includes FieldtypeMultipler, FieldtypeTable, FieldtypeTextArray and FieldtypeTextareas, among others. These enable you to have a single field that can to represent any quantity of inputs. Though they all do it in a little bit different ways. FieldtypeMultiplier lets you take any other Fieldtype (that isn't already multi-value) and turn it into a multi-value field. FieldtypeTable is a multi-value compound type that lets you keep a user-defined combination of fields contained in a group… not quite as powerful as a repeater, but it's only 1 field and has far less overhead. FieldtypeTextArray lets you have a defined quantity of inputs for any text field… like say you needed a field to represent 3 email addresses, for instance. Lastly, FieldtypeTextareas lets you have 1 field that can represent any number of named textareas while having them all be searchable from the same field. For example, you could have a single field called "content" that contains separate inputs for body, sidebar, summary and about_the_author or something like that, but they only consume 1 field, accessed via $page->content->body, $page->content->sidebar, etc. All of these Fieldtypes/Inputfields are aimed at really reducing the overall quantity of fields necessary to represent lots of data. I developed this set because I had a site with lots of similar fields, and this group of modules helped me to reduce the quantity of fields by more than 70%. However, these aren't ready for production use, so it may be a little while before I have them ready. But if you'd be interested in helping to beta test them, your use case might be about perfect.

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.