ryan

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.

You actually can't bootstrap one PW installation from another PW installation, though the idea sounds interesting. If you've got two sites sharing the same core, but running on different databases, then the only way they can share data is by taking a web service approach (the same way you'd share data with any two sites).

Soma I can't seem to duplicate this one either (also latest dev and in latest Chrome).

Soma, it sounds like output formatting is disabled in test mode. Can you try the attached to see if that fixes it? TextformatterHannaCode.module Do you know if this is an issue with AceEditor, or something about the way I've implemented it? I only ask since you mentioned Adam's inputfield had the same issue.

What URL does it show in your address bar when you get that message? Also, what version of Form Builder?

Soma, reading through php.net, it sounds like versions of PHP prior to 5.3.8 had incorrect behavior for is_subclass_of(). In those versions, the only straightforward way to determine it is I guess to use Reflection. I've added a PHP version check which falls back to Reflection in older versions of PHP, but don't have a PHP version to test it out with. Do you want to try replacing your /wire/modules/Inputfield/InputfieldPage/InputfieldPage.module with the attached and let me know if this resolves the issue? InputfieldPage.module

Wanze, Adrian is right with the _createPath() function he linked to. It maybe that you could solve it entirely simply by making it recursive, as he suggested. Actually, it might be good to just have the wireMkdir() function support creating a path rather than just a single directory... lets update that one in the core instead. The wireRmdir() already supports a $recursive argument to it, so wireMkdir() should too.

I realize I sound like a broken record in this thread, but thanks again for your great work with this language pack. This is the most complete and up-to-date language pack for PW.

Well done Horst!