ryan

Arjen is right. See /site/config.php $config->uploadBadExtensions = 'php php3 phtml exe cfm shtml asp pl cgi sh vbs jsp';

It's best to let an entire form be rendered together as a group, when possible. Like if you call $form->render(), that should render all Inputfields within the form together. This is important because it also has to process [input] them as a group. So if there are pre-rendered Inputfields in a form, they won't get processed with the form. So it creates more things for you to keep track of if you don't have all your fields rendering and processing together as a group. It's true that it's also easier to hook and extend these things if they aren't already rendered into markup. The main exception is the InputfieldMarkup type. That's designed to hold rendered markup for things that can't necessarily be rendered together with the form, like a table or some other kind of markup unknown to Inputfields. The example Soma is talking about (I think) is the MarkupAdminDataTable in ProcessTemplate that gets rendered into an InputfieldMarkup. Longer term, maybe we could come up with a new "Renderable" interface (requiring a class to just have a render() method that returns markup) so that stuff like this could be rendered together with the form fields.

If I recall correctly, post_max_size includes not just file size, but other post data as well. So it should be at least equal to, but preferably higher than the upload_max_filesize.

I've been experimenting with this by including the "rel=0" in the oEmbed call, but apparently YouTube ignores it. It looks to me like they don't support specification of this option with oEmbed, though if anyone can figure out how to do it I'll be happy to integrate it.

I wish that TinyMCE had a more graceful fallback for when a language file wasn't present. It seems like they way they are doing it is not right. Glad that worked, thanks for letting me know.

I've updated renderList to include the pagerOptions here too in the dev branch. I've got to be honest and say that arrays in GET vars have always bothered me. They are so darn verbose and ugly. Why have a query string like this: var[]=1&var[]=2&var[]=3 When you can do this: var=1,2,3 All it takes is encoding your array like this: $input->whitelist('var', implode(',', $var)); and decoding it like this: $var = explode(',', $input->get->var); That's just my preference anyway, but not suggesting it should be anyone else's unless these things also keep you up at night.

That's my understanding after doing some research online. Though I've not ever pushed those upper limits so just repeating what I've read rather than speaking from personal experience.

Thanks Soma, I'm making the same change here.

This is updated in the dev branch now too.

No idea why it would make any difference between 2.2.2 and now. There haven't been any changes to the stuff in question. For instance, the last change made to LanguageFunctions.php (where the __ function lives) was related to our previous thread, 4 months ago: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/LanguageFunctions.php The only thing I can figure at this point is PHP 5.2.4, which is known to have bugs. If you want to try and troubleshoot it a little more, try taking a look at what exactly the __() function is sending to the translator. So add this line: if($text == "whatever your text is") echo "<p>Textdomain: $textdomain</p>"; right before this: return htmlspecialchars($language->translator()->getTranslation($textdomain, $text, $context), ENT_QUOTES, 'UTF-8');

Diogo, I can't seem to duplicate here. Tried both master and dev 2.2.9. How recently did you update? I'm assuming master branch, but let me know if dev. The error indicates that a call to $modules->get('InputfieldRadios'); didn't succeed for some reason. First thing I would do is clear your modules cache. You can do this by going to Modules > Check for new modules. Does that resolve the error?

I'm happy to make any changes/improvements that you need to this module. As you can see, this module was designed for a narrower context without too many features, but now is a good time to broaden it, and I think it'll adapt easily. For starters, why don't we move renderList() to be renderList($selector) and the "limit=25, status<statusMax" can be moved to executeList, like this: public function ___executeList() { return $this->renderList("limit=25, status<" . Page::statusMax); } That way you can just override executeList. Does this solve what you need for that? Also, I've run out of time today so didn't have a chance to take a closer look at the other issue you mentioned, but if you can let me know of any specific changes I can make the same ones here.

Soma I don't have a 5.2.4 to test on, but if you try modifying that debug_backtrace does it also fix the issue? The issue with 2.2.9 showing the value rather than the label for a checkbox is unrelated -- I think I know what's causing it, it's related to some new features I recently added to the checkbox inputfield. Should be an easy fix.

Doesn't sound like you are on the dev branch. I think the problem here is just that CodeMagic only has translations for cs, en and sk. This is the only reason why I don't have codemagic installed by default. If you use codemagic with some language other than these, you'll get a javascript error. Try removing codemagic from your TinyMCE field settings and I'm guessing the error will clear up, but please let me know.

I'm having difficulty following the code due to IP.Board removing all indentation. If you can post the .module file or add it to the modules directory, I can get a better look. No need to make them translatable in the module itself. They should already be translatable from the fields editor. It looks to me like you've got this setup correctly.

This was actually fixed in the current version's source code about 10 days ago, so it's better just to grab the latest version of ProcessWire rather than replacing Pagefile.php.

Well I sort of understand, I mean I'm still using VIM and a 1986 IBM Model-M keyboard. Those maybe those aren't good comparisons. I see us requiring 5.3 within the next 6-months or so, not 2-3 years. But at the moment, my main interest is just in growing our user base, so anything that contracts (rather than expands) the user base is undesirable. But I think 6-months from now will probably be the right time to do it.

Good ideas nik! I've added a new $config->dbCache variable. When set to boolean false (in your /site/config.php file) it adds the SQL_NO_CACHE in exactly the same way you posted. This will appear on the dev branch this week.

I haven't actually moved any tutorials, at least not that I'm aware of. I see your comment on this page: http://processwire.com/tutorials/ As far as I know, that Quick-start one is the only Tutorial that's ever been in there. Although there are several subpages below it. However, those were all written by one of our users for ProcessWire 2.0, and they've not been updated since. So I worry a little about how applicable they still are. The only other places I know of that we have tutorials are the Tutorials forum here and here: http://wiki.processwire.com/index.php/Small_Project_Walktrough Let me know if I'm missing something?

The default precision value is 0. I can update this to assume no precision value until it is specifically set ... I think this makes sense--thanks. The precision field is for rounding, not formatting. I think what you want is number_format(). You could do this in your output: $value = number_format($page->float_value, 2); I could add this formatting in as a configuration option with FieldtypeFloat too, but once formatted, the value is a string, not a float. And I'm not sure it's wise for us to have this Fieldtype returning strings rather than floats. There are also localization considerations with number formatting (decimal type and thousands separator), which are also the job of number_format.

We're probably only a few days from bringing in the new jQuery into the master branch. So far I've only come across the one issue I mentioned before and nothing else has turned up yet. If that's the only issue, I'd consider that fairly minor (easy to fix). So no reason to delay further on bringing in newer versions of jQuery and jQuery UI.

Only if the template is one that defines access. Templates that already inherit access would still inherit. I guess that the most common use case would be that you'd set all your templates to not define access except for 'home' and 'admin'. You'd give all those editor roles edit access on the home template, which would then be inherited by all your others. Then your page-level access control would come in to place limits on that. But I think this would solve the issue with the "you aren't allowed" error you were getting. But I also think it would be a good way to go in general, as its building upon the access control already there (which saves some work) rather than just replacing it. In your viewable() or editable() hooks, if they are coming back 'false' then you don't even need to perform page-level access checking. Ah, I know what you mean. This is one thing I don't like about checkboxes... no way to tell the difference between unchecked and not-present. I was thinking removing them would still work, since they would not be present in the form for the render or the process, but maybe I'm overlooking something. You might try this (below) instead, which doesn't remove them but designates them as hidden and thus not rendered or processed: public function hookBuildForm(HookEvent $event) { if(wire('user')->hasRole('paakayttaja')) return; $form = $event->return; $field = $form->get('view_roles'); if($field) $field->collapsed = Inputfield::collapsedHidden; $field = $form->get('edit_roles'); if($field) $field->collapsed = Inputfield::collapsedHidden; $event->return = $form; } If that doesn't do it, we might try and just get away from checkboxes and use either radio buttons, select multiple or asmSelect instead (something that have a distinction between not present and not checked).

Namespacing not supported by PHP 5.2.x which currently represents a large base of ProcessWire users. Probably by ProcessWire 2.4 we'll require PHP 5.3 at which time we can namespace.

Soma's example is the way the InputfieldForm is meant to be used in this instance. Forms in HTML don't have a 'value' attribute, so we repurposed it in InputfieldForm to function as a way to put in whatever you want. However, if you wanted to do it the more traditional Inputfield way (using InputfieldMarkup), you could also do this, though it's not necessary: ... $form = $this->modules->get("InputfieldForm"); $form->attr('action', $url); $form->attr('method', 'post'); $form->attr('id', 'myform'); $field = $this->modules->get("InputfieldMarkup"); $field->value = $table->render(); $form->add($field); ...

Nik, this has been pushed to the dev branch: https://github.com/ryancramerdesign/ProcessWire/commit/eecd862a6ecf90f2c6b1c173c4d129c5152a31e7 In addition adding in the isGuest() check and the has_parent check, I changed the line you added to be this: // optimization: if parent, parent_id, template, or templates_id is given, and an equals '=' operator is used, // there's no need to explicitly exclude repeaters since the parent and/or template is specific if(in_array($name, array('parent', 'parent_id', 'template', 'templates_id')) && $selector->operator == '=') $includeAll = true; Basically added in 'template' and 'templates_id' since those are also specific enough so as to warrant exclusion of the filter. And added an extra check that the operator was "=", since if they used something like not equals (!=), or greater than/less than (>< <= >=), that would still warrant inclusion of the filter. But just in case I got any of this wrong, I've kept it in the dev branch for further testing.