ryan

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.

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

We think it's an issue between the latest Chrome and TypeKit, as we haven't heard of it occurring in any other browsers. Also haven't heard of it re-occuring after a refresh, so most likely they made some change at TypeKit that needed a JS refresh. Though please let me know if it continues to recur, or if anyone else sees it occur in any other browser.

I'm definitely seeing old cached stuff there, or remnants from the old admin theme. Particularly on that uninstall box, the colors of the PW 2.3 admin theme are bleeding through. Do a hard refresh on your browser cache. Make sure that your entire /wire/ directory was replaced in it's entirety and not replaced into (with potentially merged files). Lastly, make sure you don't have a /site/templates-admin/ directory present.

@justb3a I'm using PHP 5.6 here but not seeing the issue. It looks like something is throwing some output when it shouldn't, causing it to interfere with the resulting JSON from the ajax request. You can observe what it is by clicking your Network tab (from your screenshot above) and then click on the ajax request that resulted from your upload. From there you can observe details about the request. Click on the response tab, which should give you a plain text view of the response. Most likely you'll see an error message (or some other HTML output) preceding the JSON. What does it say?

Looks like a bad typo on my part, sorry guys. I've corrected it.

Actually it gets even simpler than that: $statusLabels = $page->status(true); $statusLabels is an array of names/labels applicable to the page.

I just pushed an update to the module that corrects the issue. This module used a naming format for a file that's not compatible with PW 2.5.11+ (though sounds like it still may have worked up until the latest, but really shouldn't have). If you grab the latest it should work now.