ryan

Soma, I still can't duplicate this one. Tell me if I'm not setting it up correctly. I have a field called "Test Toggle" that when checked shows my repeater. When unchecked, it shows another fieldset called "Test Fieldset" (which itself contains a single text field). See the screenshots that demonstrate the checked and unchecked state of "Test Toggle". The "show if..." rule I've attached to my "rates" repeater is test_toggle!='' and the rule I've attached to my "Test Fieldset" is test_toggle=''. This site already had multi-language enabled. The screenshots don't show it, but I also tried adding a multi-language title field to the repeater, just in case. But that didn't make any difference. test_toggle unchecked (test_fieldset shown): test_toggle checked (test_fieldset hidden and rates repeater shown): Can you think of anything else I should try?

I've had this same issue when updating Foundation. For some reason they've got odd file permissions in their download and they need to be adjusted when moving to a web server. Thanks for the tips. I have added these to my version of the profile and will test and commit them. I like Foundation and briefly considered using it behind an admin theme, but found there's just not much benefit in doing so. Most of the stuff that Foundation provides seems to be more worthwhile for front-facing stuff. I went through each of Foundation's features and found none of them would get used on the admin side, so it didn't seem to be a worthwhile effort. See the note here about the $useMain option.

Add this to your template file: $useMain = false; See the note about this in the /site/templates/_init.php file

That's fine with me, though it doesn't necessarily have to be on GitHub. I think it's just as easy to post any new SCSS file(s) in here along with a screenshot of what's proposed. I think there was a bug in there when I first posted it related to this (colors switching back to main). I did fix it and think (hopefully) that was fixed in yesterday's commits.

@adamspruijt, yes please submit any feedback you'd like, that's what this thread is for. I would just request that any feedback be based on actual use/testing the theme itself rather than the screenshots, as the screenshots are fairly limited in scope relative to the theme. We may have to wait to act on some of the feedback until we approach the bigger admin-theme project in the future, but all feedback is appreciated either way. For instance, if there is a consensus that the page list actions are too small, I'll be glad to increase the default size of them. That's also a fairly simple thing to do. Chances are that the value in your session was already set to something, and the session value overrides the $config value. To resolve that, just set your session value to match the $config value, or clear out the session value by specifying an unknown color theme. /processwire/?colors=classic /processwire/?colors=poopst I'm not sure that I like the sound of that, but if you mean post a color theme file here that's great.

It actually does sound like files are missing (or unreadable). If it's fixed again by replacing your /wire/ directory, then I would suspect your web host. Some web hosts run scripts nightly that go and look for files containing certain names or patterns which they assume to be problematic from a security standpoint. Unfortunately they far from perfect, and they flag files that have no problems at all. I believe this is because of filenames similar to WordPress filenames that have issues. For instance, Dreamhost apparently flags ProcessWire's /wire/core/Page.php, and they can't even figure out why. Once they flag it, they make the file unreadable, essentially breaking the installation. I've been in contact with one user that is having this problem with Dreamhost. This could be what's happening in your case, though with one of the /wire/modules/Fieldtype/ files (FieldtypeURL?). Check that all of those files have full read permissions. Also, check any Fieldtype modules you have in /site/modules/.

It doesn't sound like a DB migration issue, it really sounds like a file migration issue. My best guess is either: 1) File permissions on your Hanna code modules rendered it unreadable to your web server; or 2) that you had Hanna code installed as a symlink on your source server, and the symlink didn't migrate or didn't match up on the target server. That would explain why you'd have a Hanna Code Setup menu item and DB entries, but no ability to run it. Installing through Modules manager would have fixed it since it knows to install the files into the right place with the right permissions, etc.

While either of those solutions may work for this case, Radek's suggestion is the safer and recommended one. Your guest user is the default user when no user is logged in, so it's best to keep the guest language as the default. There is nothing about the default language that says it has to be English. You can make your default language whatever you want it to be. But the purpose of having a default language is exactly for situations like this. Plus it means you can code your templates in a manner that isn't dependent upon one language or another.

It really depends what cache you are talking about? Template cache, Markup cache, runtime memory cache, ProCache? All of these caches usually clear themselves for the saved page, so you don't usually have to consider the cache except for pages that may be pulling pulling data from a separate cached page.

Jonathan, when ready, would you mind adding this to the modules directory? Not everyone sees the modules here in the forums and we want to make sure those interested are able to find it.

That sounds like an interesting idea, but that's not currently possible. When PW bootstraps, it loads several things from the database into memory, like template and field definitions, etc. When you make another database connection, you are just connecting to another database and not bootstrapping all of PW.

Edit any template, click to the "family" tab, and choose at least one template for "allowed templates for parents". A new option will appear that says "Show in the add-page shortcut menu?". It also includes description text that states the following: Conditions required for this to work You must select a parent template (see: "allowed templates for parents" above). If more than 1 is selected, only the first will be used. The selected parent template must have defined this template as one allowed for children. There may only be one instance of a page using the parent template in your system. The admin theme must support this feature. If you are used to using family settings to limit what pages can go where, then you'll find that the above conditions match up with what you'd usually do. Meaning, PW will auto-discover what templates can be shown in the shortcut menu. If it's showing something you don't want it to, then you can turn it off by selecting "No" in the shortcut menu question for any of those templates. Does anyone else agree? Currently the base font size is 13px (same as PW has always been). I could always bump it to 14px. Though it is quite a size difference, (too big to my eyes, and I'm on a 30" 2560x1600 screen where everything is already small). It is defined in one place, and all other font sizes (except #footer) are affected by this rule in main-[colors].css (or main.scss). #masthead, #notices, #content, .ui-dialog { font-size: 1.3em; } Beyond that, the best way is to just increase the font size in our browser. I tend to do this a lot on sites that I visit to increase the font-size. In OS X, it's CMD= to increase and CMD- to decrease (I'm assuming it would be ALT= and ALT- on Windows to do the same). Hit reload a couple times, sounds like you may have an older cached version of InputfieldFile.js stuck in your browser cache. Thanks for the suggestion, I'll give it a try. Though I'm pretty much using CKEditor exclusively now, but TinyMCE is still the default, so we've got to make sure it looks good. That looks interesting, though I'm not sure you even need PHP for this. I didn't give SASS a try for a long time in part because I assumed there would be technical requirements, multiple things to install, configuration, new stuff to learn with no time to do it, new terminology (Compass? still not sure on that one), etc. I was surprised that it didn't take anymore than what is on that 3 line box at the top of the SASS homepage. Apparently OS X already comes with a running copy of Ruby, so I didn't have to do anything other than type "sudo gem install sass" and then it all worked. So for those running in OS X at least, it is surprisingly easy to get going. Learning the basics of SASS was just as easy, as it's all right there on the SASS homepage. Maybe ProcessWire should have such a helpful homepage like this.

The grid view is primarily for sorting or seeing it all at a glance. It's not a great view for entering content. This is not meant to replace the existing list view, just provide an alternate that you can toggle when it suits your need. In my case, a client needed the ability to sort large groups of photos more easily, so I made the grid view primarily for that reason. Currently it starts out in list view but provides the little icon at the top that lets you switch to grid view. I'm not sure it'd be good to start in grid view just because you can't delete or enter description/tags... though you can upload. I've not tried it yet, but I'm also assuming that the grid view would hide any options for the Thumbnails/CropImage module as well. But if there's demand for starting out in grid view, I'm open to adding the option. It's just that the grid view is fairly targeted towards sorting rather than general management. Down the road, we may be able to add more options to the grid view too. Thanks, it looks like that could happen if there is a leftover parent template ID for a template that has been deleted. I've added a check for this so it'll appear on dev later today.

A couple small updates today to InputfieldImage and InputfieldFile, on the dev branch. You can now double-click the trash icon associated with a file/image, and it will select (or unselect) all files/images for deletion. The image inputfield now has a grid-view option. To switch to it, click the grid icon seen in the upper right corner of the field. This mode makes it more convenient to sort lots of images. Below are screenshots of the regular view and the grid view. You can toggle between them just by clicking the icon. While these screenshots use the development admin theme, this all works in the regular/old admin theme as well (and 3rd party admin themes I'm assuming too). Another update to mention is something sort of like the HelperFieldLinks module, but not quite as comprehensive. This works only in the development admin theme. If you hover the little down pointing angle on the far right of the Inputfield, it will append the field's name to the label. This is helpful for instantly telling what the field's name is from the API side. In this screenshot the "agent_files" part you see in the label appears only when that icon on the right is hovered.

This is possible now, but requires just a little bit of development (and only a little bit, thanks to SASS). 1. Copy one of the /site/templates-admin/styles/_colors-*.scss files to a _colors-something.scss file (replace "something" with whatever you want to call your color scheme). 2. Now edit your /site/config.php and add this line: $config->adminThemeColors = 'something'; // replace "something" 3. Edit the file and adjust the SASS variables in your _colors-something.scss file to suit your color scheme (but read the rest below before doing so). 4. Edit the main.scss file and change the first @import line to reference your new colors file. 5. I recommend keeping a watch on your main.scss file so that it recompiles it to a single main.css file anytime you make a change to any of the files. That way you can just view the changes in your browser as you make them to the _colors-something.scss file. From the terminal, you'd do this, and then let it run while you work in another window: cd site/templates-admin/styles/ sass --watch main.scss:main.css From there you should be able to tweak your color scheme and see the changes immediately as you make them, every time you reload your browser. I had never used SASS before this project, and am not taking advantage of all that you can do with it. But I found it super easy to get started with (literally 5 minutes, just read the homepage) and a lot simpler to use and work with than regular CSS. This is probably old news to most of you that have been using these pre-processors for years, but I've never been an early-adopter, so tend to wait for things to become standard (and then some) before I start using them. And it seems like SASS (and LESS) have become quite standard.

I think it kind of depends on the situation. There are many situations where I like how defined the boxes are, even if they are boxy. That's why the default admin theme hasn't changed much since the beginning. In other cases, I like the borders to be more faint, like what's in this theme. I think most people probably prefer the lighter look that. Ultimately, this theme will support either, but in the interest of keeping the scope small, I'm probably just going to focus on the lighter color schemes with this, and continue to use the old admin theme for situations where I want the boxes. Time is not permitting but this theme was built out with all the color definitions as SASS variables, so changing out the color theme is pretty simple already, but still a developers task. I'm just going to focus on getting a few good color schemes out there as choices, and I think the longer-term/bigger admin theme project should potentially pursue the ability to change colors in the admin. But probably not this project. Thanks, that's my favorite one too. I've been looking the PW blue palettes for too long. But I'm going to continue tweaking all the palettes and adding a couple more (one will be based on Nikola's Futura Remixed color scheme). If anyone here with a good eye for colors sees anything that looks amiss, please suggest changes. Though try out the actual theme, as my screenshots are a little off with the colors (I've got some weird color profile settings to deal with one of these Dell high-color displays, and it tends to mess with my screenshots). I think this is something that may be pursued in the bigger/longer-term admin theme project, but not in this interim project. Thanks I was able to reproduce as well. Looks like I need to wrap the mouseleave() in a 250ms setTimeout() for Firefox, at least that seems to fix it here. I'll commit this update tomorrow.

Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.

Modules don't usually have to think too much about multilanguage, unless they are themselves built to provide additional multilanguage features. I think we need a little more info and perhaps an example of what you are trying to do? Also, is this related to the Pages Web Service module, or a question independent of it?

It sounds like the time settings being recorded for sessions and the time settings on your server are disconnected. I'm wondering if it could be something to do with timezone. I'm honestly not sure on this one, but happy to take a closer look at it.

There isn't any dependency on 'created' or 'modified'. You can use any date field you want to. In fact, most of the time I use a custom date field for this. However, you have to specify it when you render your feed. The one that you set in the module settings is only the default value that takes effect if you don't override it when rendering your RSS feed.

That's correct. Incorrect. You'd want to add some additional GET or POST variable to your AJAX requests in order to differentiate them and bypass the cache. The drawback is that only your regular requests will be cached, and your AJAX requests won't. You can always get around this by using MarkupCache for caching either type of request and delivering the appropriate one according to the request method (regular vs. ajax), but it'd have to be a pretty slow/heavy request before I'd bother with that. Perhaps a better way to achieve it would be to use pagination, as paginated URLs are fully cached (using PW's template cache). That's assuming you don't need pagination on the template for another reason. But by enabling page numbers, you could delegate your regular full-page request to /path/to/page/, and your ajax requests to /path/to/page/page2/, and page3, page4, etc., as needed. Your template code could detect it like this: if($input->pageNum == 2) { // deliver ajax request } else if($input->pageNum == 1) { // deliver regular full-page request } else { throw new Wire404Exception(); // prevent caching } Partially correct. If you use ProCache, you can cache URL segments, but not the results of #anchors, or requests containing GET/POST variables. You'd want to convert those to URL segments and then you could cache everything as needed. For example, rather than /path/to/page/?fragment=version you'd use /path/to/page/fragment/version/, and "fragment" would be represented by $input->urlSegment1 and "version" would be represented by $input->urlSegment2.

I think Martijn is right and this really is a memory_limit issue. Especially if that file is an image, as it'll have to be processed to generate a thumbnail too. And once uncompressed for processing, a 90 MB image is going to be quite large. Even if not an image, 128 MB is still too little for this situation. I would bump it to 256.

Image fields can't be used with dependencies at present because they are ajax-upload driven. As a result, the page receives the image before it knows about the dependency condition being met, and the image is refused. I suppose this could be solved by having dependencies operate only at the Javascript level and not at the server side, but that wouldn't be as safe either. I'll keep thinking on this one. Is this in the page editor or in a Form Builder form (or somewhere else?). If it's a Form Builder form, it be good if I could take a look at an export of it, so I'd have a good test case to debug from. Please PM to me if possible.

What you are talking about is relational data, and you definitely would not want to draw these relations by searching for the person's name (after all, there might be two John Smith's too). You want to use the Page reference field type, which lets you reference one page from another. Create a field called "people", and choose "Page" as the field type. On the "input" tab, choose "person" as the template to use for pages (or whatever you've called your template for people), and asmSelect (or Checkboxes or Page Autocomplete) as the Input type. Save. Add your new field to your "event" template. Edit an event, and now you can select the people that are related to the event. If you later change the person's name or anything like that, then it doesn't matter. To list the people connected with an event, you'd just do this in your code: foreach($page->people as $person) { echo "<p><a href='$person->url'>$person->title</a></p>"; }

Do you guys think it makes sense to bring LanguageFieldTabs into the core? So far I haven't come across a multi-language site install where I wouldn't want it, so starting to wish it was just there by default.