ryan

Hard to tell without seeing the code -- can you post the non-working code here?

Awesome job Adrian! I can't wait to use this one. I'd be using it right now if I weren't holding a baby in one arm and typing with the other. But I did browse the code and thought it looked great.

There's a few ways to get at them.This might be the most direct: $array = $field->getArray(); // or $array = $field->getTableData();

Soma, I like the direct simplicity of your solution here. The $user instead of $this->user was a typo on my part, not intended. PHP usually gives me an "undefined variable" notice to let me know about those things. But to explain the purpose of the temporary variable _language_tmp, that is so that the original setting could be restored. It's possible that $user->language is something different than $this->setLanguage, perhaps due to something changing it in the site's templates during the course of program execution. The only way to capture that is to store it in some temporary place before save and then restore it after save (which is what I was attempting to do). Though it's probably a rare thing, so if the new solution you've tested is working, then I'd rather just stick with it and approach the other issue if it ever comes up (I don't think it will). Thanks for debugging this and coming up with a nice simple and working solution. Just to confirm, this solves it? Or are there still things that aren't working still?

I'm not sure I agree that it's a good idea or that it would make more sense to clients. I think what makes the most sense to clients is when structure represents reality, both front-end and back-end. In that context, the homepage is the root page, the common ancestor of all others. The more you abstract those things, the less sense it makes to clients, at least in my experience. As a result, I encourage people to use the homepage as the homepage rather than trying to abstract it to somewhere else. If you are going to abstract it, then it depends how you do it. I would avoid handling it from the htaccess and instead edit your /site/templates/home.php to load and render the other page that you want to represent the homepage. $otherPage = $pages->get('/path/to/your/abstracted/homepage/'); $otherPage->you_be_homepage = true; echo $otherPage->render(); In the page represented by that path above, you'd want to have it throw a 404 (via it's template) when you_be_homepage is not set, just by throwing this at the top. if(!$page->you_be_homepage) throw new Wire404Exception(); or make it redirect to the root page: $session->redirect('/'); Using this strategy, you shouldn't have to consider any effects on SEO as the abstraction will be invisible from the outside.

In this case I think it's fine to do what you did, rather than extending. Though what you'll miss out on is when fixes or additions are made to the core modules, your module won't automatically inherit those. I usually try to extend or better yet, delegate, when it makes sense. But sometimes it can be a less direct path. So it does come down to how much time you want to put into it as well. I'm not exactly sure why that would be occurring in your case–is your module file in /site/modules/? One way you can resolve it is to add this at the top, before the class declaration: include(wire('config')->paths->modules . 'Fieldtype/FieldtypePage.module'); or wire('modules')->get('FieldtypePage'); But I'm surprised you'd have to do that in this case, at least I've not had to when extending a core module. If running APC, you might want to apc_clear_cache(); just in case.

There are limitless possibilities, so instructions kind of depend on what your need is. Most likely "author" would be the name of the role you would create. What do you want the author to be able to do? I can follow-up with instructions on how to do it. Thanks for letting me know, I have unpublished that page temporarily until I can update it. Didn't realize we had such old info there!

There are other 3rd party modules that might store files in a page's files directory as well. So that's why that unlink() is left commented, and why this is better left as a script that you adjust according to your installation, rather than as a ready-to-run module or something. It only knows about core-managed files.

I sometimes end up with orphaned files as a result of doing mass imports during development. My code won't be quite right the first time around and I'll end up with extra and/or duplicated files. At least that was the case this last week. It was on a pretty large scale, so not something I wanted to clean up manually. Here's how I cleaned them out. Place this in a file in your site root called clean-files.php and then load it in your browser. /clean-files.php <pre><?php ini_set('max_execution_time', 60*5); // 5 minutes, increase as needed include("./index.php"); $dir = new DirectoryIterator(wire('config')->paths->files); foreach($dir as $file) { if($file->isDot() || !$file->isDir()) continue; $id = $file->getFilename(); if(!ctype_digit("$id")) continue; $page = wire('pages')->get((int) $id); if(!$page->id) { echo "Orphaned directory: " . wire('config')->urls->files . "$id/" . $file->getBasename() . "\n"; continue; } // determine which files are valid for the page $valid = array(); foreach($page->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFile) { foreach($page->get($field->name) as $file) { $valid[] = $file->basename; if($field->type instanceof FieldtypeImage) { foreach($file->getVariations() as $f) { $valid[] = $f->basename; } } } } } // now find all the files present on the page // identify those that are not part of our $valid array $d = new DirectoryIterator($page->filesManager->path); foreach($d as $f) { if($f->isDot() || !$f->isFile()) continue; if(!in_array($f->getFilename(), $valid)) { echo "Orphaned file: " . wire('config')->urls->files . "$id/" . $f->getBasename() . "\n"; // unlink($f->getPathname()); } } wire('pages')->uncache($page); // just in case we need the memory } When you can confirm that it has found the right files (and no false positives) uncomment the "unlink" line above to have it remove the files on the next run.

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.