ryan

@Webrocker the Agency support/upgrades period should last for 1-year, regardless of whether a renewal or not. If you find that not to be the case, please let me know and I'll update your account to correct that. Though I'm not sure which account we are talking about, as you mentioned it was one separate from yours? Also, to add you to the Agency support, just have the purchasing account send me a PM indicating what other accounts they want to be attached to the support, and I'll be happy to add. Thanks.

You've definitely got something including that file somewhere, somehow. Otherwise you wouldn't see the text that it is outputting. Here's a shot in the dark, but do you have Adrian's 404 Search Results Generator module installed? That module loads your search template when a 404 occurs. If something on your admin page were generating a 404 (like a missing css file, image file, etc.) then it's feasible it might load that module, which would make it output the text you've described?

The only place where I can find that text phrase is in our default site profile's, in the search.php template. What you've mentioned makes me think you are seeing this in the PW admin? It sounds to me like somehow your /site/templates/search.php file is getting included in whatever page you are viewing. The first thing I would check is the template (admin?) settings for page where you are seeing this message, on the "files" tab. This message occur if your /site/templates/search.php is set as an auto-prepend or auto-append file. You might also check your /site/config.php $config->prependTemplateFile and $config->appendTemplateFile. Lastly, look in your /site/templates/admin.php file to see if it contains what it should–perhaps someone overwrote it with the contents of search.php?

Ivan, the input pattern is part of the input module (InputfieldText), and performed as part of the input validation. When assigning values from the API side, it is not considered user submitted input, so the Inputfield is not involved, and likewise the pattern is not a factor. When editing a field, you'll see "Details" and "Input" tab. All the settings on the Details tab are specific to the Fieldtype in use, whereas all settings on the Input tab are specific to the Inputfield. While we could move a setting like that to the Fieldtype, it's not ideal because plenty of other Inputfields extend InputfieldText, and are able to likewise benefit from the pattern support that it provides. Further, Fieldtypes are most efficient when they only perform very quick validations (like validation for type) since the Fieldtype's validation/sanitization occurs every time a value is populated to the page from the API (like every time a page is loaded), and validating a regex pattern is a relatively slow process.

tpr's solution is better than the one I posted. To take it a step further, those _x() functions never even need to execute. They can simply be contained in a PHP comment, as they only need to be visible to the language parser, which parses the files directly and doesn't execute the with PHP. So you could do this: /******************************************* Intentionally commented out ​// Search_x('Search site', 'Search'); _x('No matches', 'Search'); // Forms _x('From', 'Forms'); _x('From email', 'Forms'); _x('To', 'Forms'); ... *******************************************/ Of course the actual t() function should not be commented out though.

@Fester your settings look correct to me. A page using that template would only be visible to superuser, editor and registered user roles. So something must be overriding access control in your case, like Teppo suggested. Double check that you are testing with a guest user. By that, I mean logout and test, open in different browser (that's not logged in), or open the page in an Incognito/Private window. I think Teppo mentioned all the possible things, and I don't have more to add to it, but please let us know what you find.

@ro-bo the Options fieldtype behaves like a Page fieldtype. For more information see the documentation page here: https://processwire.com/api/modules/select-options-fieldtype/ In terms of having a blank option selectable, all that you need to do is just make sure that you don't have the "required" box checked (on the Input tab). You don't need to add your own blank option. I do think it's unusual that you are getting a "1|2" or "1|4" after choosing "Blank". I've tried to duplicate that here (with select-single value) but can't. If I output my value after choosing blank, then I get just blank. My test is just "echo $page->option_field;" Can you post some code of how you are checking the value? I would also be curious about your settings for "which options are pre-selected" and how your options are defined in the "what are the selectable options" textarea.

I use a similar solution to a _strings.php file, and include it from my _init.php file (prependTemplateFile), so that it's available to all templates. But I bundle all the translated values into a new function (which I'll call _t(), but you could name it whatever you want). So you can call upon that _t() function anywhere that you'd call a __() function. For instance, in your /site/templates/_strings.php file... function _t($label) { static $labels = null; if($labels === null) $labels = array( 'Yes' => __('Yes'), 'No' => __('No'), 'Maybe' => __('Maybe'), 'And so on...' => __('And so on...') ); return isset($labels[$label]) ? $labels[$label] : $label; } From there, you can replace any __('label') call with _t('label'). In this manner, you only need to translate your _strings.php file, and all the other template files can use the translated labels. For the cases where you need to translate text that only exists in a particular file, then you'd continue to use the __() function as usual.

Since admin themes are modules, the templates-admin serves as a fallback in case no AdminTheme modules are able to be loaded for one reason or another. That admin theme is there so that you can still login and fix your system if everything goes haywire for whatever reason… though I don't know of many scenarios where that would be the case, but consider it an insurance plan. Since it's there, it also serves as a good location for files that must be shared among all admin themes (whether the AdminTheme modules, or the fallback theme, or an older /site/templates-admin/). For example, the inputfields.js file, the debug.inc file, font-awesome, and possibly more in the future. It serves this purpose well and I don't see any reason to get rid of it. We may update it at some point to change the look of it, but also don't see it as much of a priority since nobody ever sees it except in rare development situations. Lastly, it's the only thing that enables use of older /site/templates-admin/ themes, for those that need to use the older system of admin themes for one reason or another (like folks that have company-customized admin themes from long ago, but still want to use a newer PW version).

Great job setting this up Netcarver! Just spent some time browsing through the store and I like what you've got here. I especially like this shirt (dark blue with just white PW logotype across the front). Also, that's really kind of you to want to send me 50% of what you make from this, but I've not participated in setting this up at all–you've done all the legwork, and you should keep whatever you make from it. I'm just glad to see some nice PW merchandise here. These shirts are good advertising for PW and help to spread the word.

PW has to support a broad range of MySQL versions. One of PW's distinctions is making all of the data highly accessible, behaving as if it was all in memory ready to be used, while still being able to scale to millions of pages. One of the important keys to this is fulltext indexes. InnoDB did not support fulltext indexes for a long time, not until recently, in the overall MySQL timeline. While InnoDB now supports fulltext indexes, that's only if your server has a newer MySQL version that supports it, and a great many out there do not support it. Whereas it is universally supported on MyISAM, and has been forever. PW also performs reliably and particularly well with MyISAM (though does with InnoDB too). Like SiNNuT mentioned above, there are no foreign keys in MyISAM, so it's not even a consideration to be debated. While having foreign keys would have certainly saved time on the development side of PW, and are a nice-to-have feature at the DB level, the lack of them is not going to "lead to data inconsistency" either. We manage our table relations very carefully and thoroughly, as we know we don't have foreign keys managing that for us. To the end user of PW it makes no difference. I'm quite certain that whatever issue you are running into has nothing to do with the lack or presence of foreign keys. You can take advantage of InnoDB in PW now if you want to, and we've confirmed it working quite well across several installations. In fact, it's now an installation option available to you. If you click on the gear icon during install (MySQL settings screen) you'll see an experimental option to use InnoDB. While PW won't use features that aren't in both MyISAM and InnoDB (in order to be compatible with both), there are still some benefits to using InnoDB. Specifically, if the power goes out on your server, you won't have a potentially crashed table (needing a repair command). In addition, tables aren't locked during writes, making it work better in high traffic environments that are having to do a lot of INSERT or UPDATE operations in PW (i.e. constant updating or importing pages).

@root based on this and the other thread, I'm pretty certain that something external (whether Apache module, configuration, or PHP setting) is interfering with the POST requests on your server. Your repeaters scenario should be just fine as is, so I don't think that's the problem. You mentioned that you submitted the form, and at one point got a 200 rather than a 301. That indicates that most likely PW didn't detect any POST data at all, though there's something you can do to test. Please enable debug mode (/site/config.php, $config->debug=true), then reproduce that situation where you get a 200 after submitting the form, and no data saved. While on that screen, scroll to the bottom and click on $input->post in the debug accordion. Examine the raw contents of the POST data there. Look for truncated data. If you don't see an $input->post then that means there literally was no POST data at all. At that point I would take PW out of the picture and start experimenting with POST data outside of PW to see if that makes it easier to isolate what is interfering with it.

There seems to be something else interfering with your textarea field. I just tried to duplicate, both with 32768 random bytes in a textarea, and with your exact markup posted. But no problems saving either. There are no length limitations imposed on textarea fields, unless used without a Fieldtype (like in FormBuilder, or in other non-Page Inputfield forms). In what context are you using the textarea field (if not just a regular page field), what input type are you using with it (if not regular textarea), and what settings have you configured with it, on both "details" and "input" tabs? Though you may want to look at the following first: The "forged" error, as well as silent data loss seems to suggest that the data is getting truncated before PHP gets access to it. Given that you have silent data loss, the forged error is most likely occurring because the CSRF token is not even getting sent (perhaps due to the entire post request getting truncated). I would look at your PHP settings like post_max_size, as well as max_input_vars, to make sure you aren't hitting up against those. From the sounds of it, you are hitting up against a configured maximum in PHP or Apache.

Thanks–it was an issue with Friday's fields update to support dynamic insertion. This is fixed on the current dev branch (put in the fix yesterday).

This is the sequence of code that gets executed before that error: $dir = wire('config')->uploadTmpDir;if(!$dir || !is_writable($dir)) $dir = ini_get('upload_tmp_dir'); if(!$dir || !is_writable($dir)) $dir = sys_get_temp_dir(); if(!$dir || !is_writable($dir)) throw new WireException("Error writing to $dir. Please define \$config->uploadTmpDir and ensure it is writable."); I don't think the trailing slash matters here, unless that causes Windows to return the wrong permissions for the directory (?). My best guess is that the values returned by both your PHP upload_tmp_dir and sys_get_temp_dir() are not writable or don't exist. Manually specifying the $config->uploadTmpDir would be the best course of action here.

Sounds interesting. Here's one way you can do it: $table = $fields->get('your_page_field')->getTable(); $query = $database->query("SELECT data FROM $table GROUP BY data"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $items = $pages->getById($ids); // $items is a PageArray echo $items->implode("\n", "<a href='{url}'>{title}</a>"); If we were to add this to the API, I think I'd want to make it accessible from a regular find() selector, rather than as a separate findSelectedPages method. That way it could be used with things like InputfieldSelector. Perhaps something like this: $pages->find("your_page_field=:selected"); ...where ":selected" is a keyword is would recognize to execute this behavior.

It does sound like a directory separator issue, but not really clear where. Can someone post a translation JSON file that has the issue?

When a field is only made viewable (whether by permissions or by the field's visibility setting), only its content is rendered in the document, not its form field. When it comes to visibility, field dependencies are a front-end/javascript task, so it needs that form field see what the value is. It doesn't work in your case because the field you are using for your dependency physically doesn't exist in the form (since it is not editable). In order to support this dependency scenario, we may need to add an option to allow rendering of the <input> rather than just the contents, similar to what we do for language field permissions. The user would still be able to change it (and affect the dependencies that way, though only on the front-end), but any changes they make to non-editable fields wouldn't be saved.

I was actually thinking of converting all feature request/enhancement issues to something in the PW website (powered by PW pages). Something like the sites directory, with the ability to "like" requests, so that the most requested ones could rise to the top and get more focus. This would also get them out of GitHub, so the focus there can be on issue reports. Though I think it's good to still submit feature requests at GitHub, but I would just move them to the more dedicated system and close them out there once that's done.

I'm not seeing the same error here. I setup a multiplier that uses "Textarea" and then populated values and did a search using the "%=" operator. It successfully located the page I put it on. Double check that your "field type to multiply" specified on the details tab for Multiplier is "Textarea". If it still doesn't work, what version PW and Multiplier are you using?

When it comes to output, options fields are designed to mimic the behavior of Page fields. So $option->title is the primary field you would access from each option when doing output, i.e. echo $page->myfield->title; Or if a multi-value field: foreach($page->myfield as $item) { echo "<li>$item->title</li>"; } Other properties you can access are 'id' and 'value'. In most cases, you will just be accessing the 'title' though. The 'value' property is only used if you defined separate values for your options, i.e. "id=value|title". When it comes to manipulating values, it's really simple. Just make sure that output formatting is OFF ahead of time (like Kixe mentioned above). This is true for any ProcessWire field where you intend to manipulate values. If output formatting is ON, then it's simply not going to work because the Page is not in a state to have it's values manipulated. So for those of you above where it didn't work, chances are your $page output formatting was on. Turn it off like this: $page->of(false); Assign the selected option title you want to to field directly (as a string value). This is just like previous examples on this page: $page->myfield = 'Yes'; If you want multiple selected options, then assign an array of option titles, i.e. $page->myfield = array('Yes', 'Maybe'); You can also use a string to set multiple titles (separated by a pipe "|"): $page->myfield = "Yes|Maybe"; You can also set by the option's 'id' or 'value' properties, using the same syntax as above. Note that when assigning positive numbers, they are always assumed to be the 'id'. So if your option 'title' or 'value' (if used) needs to be numeric, you might want to specifically assign your 'id' properties to be that same number to reduce confusion, i.e. "1=1". If using separate values and titles, it will look for a matching title first. If/when you want to save the changes, then follow it up with: $page->save(); // this $page->save('myfield'); // or this, if you don't need to save anything else

If you see a JS error form file upload, there's an way to find out exactly what the source of the error is, at least in Chrome. Open the developer tools in Chrome: View > Developer > Developer Tools. Click on the "Network" tab in these tools. You should see columns for "Name, Status, Type, Initiator, Size, Time, Timeline" (if you don't, drag your dev tools to be a little larger). Drag in a file to your file field that's not working, to attempt to upload. You'll see a new item appear at the bottom of your Network tab that looks like "?id=123", where 123 is the ID of the page you are uploading to. Click that "id?=123" item. It'll open a new panel to the right with several new tabs. Click the "Response" tab. In this Response tab, you'll see some kind of error message, likely followed by some JSON code. You may be able to tell what the next step is from the error message. For instance, maybe it's some 3rd party module reporting an error directly to output, or maybe it's a 403 error from Apache, indicating that mod_security is interfering with your file uploads. It could be anything. If you can't tell what to do next from the error, paste it all in here so we can get a better look and we can suggest what to try.

Antispambee sounds like a good one! Does it use some external library that is separate from the Wordpress Plugin? We actually do have a means of integrating more types of spam filters into comments, and it's via extending an abstract module class called CommentFilter. This is what CommentFilterAkismet extends, and we could add additional modules that also extend CommentFilter and implement the abstract methods. What's missing right now is for FieldtypeComments to check for additional CommentFilter modules. However, that was always the intention to expand it, and I'd be happy to add this capability, and maybe someone else can implement a new CommentFilterAntispambee or other(s) so that we've got more options here.

Evan, I think your solution is a good one, but it definitely leaves the question of why it's necessary on these particular installations. It's like the database changes got previously applied, but the schemaVersion stored with the $field didn't. I will add your changes, but also think it's hiding another issue that I'd like to find a way to reproduce so can determine the source of it. If anyone is able to reproduce on a fresh install, please let me know.

Just wondering if anyone has been able to duplicate this? Since I'm not able to duplicate locally, I'm having to look closely at the error messages: Did these two occur immediately after each other? On one hand it's saying the column doesn't exist. PW catches that, and attempts to add it. Then it's producing a "column already exists" error. So it's like the column both exists and doesn't exist at the same time. The next thing I would suggest is running a DB repair, as it sounds like something might be corrupted. Though I'm interested to hear if anyone else sees the same problem. We did have an issue here a couple months ago on the dev branch, but it was fixed. It's always possible that something about your DB still has a leftover from when there was a problem. I'm curious if you are able to duplicate the issue on a fresh installation of 2.6? A good way to test would be to install with the "languages" profile that it comes with. Thanks.