ryan

I don't know when it ends, but they currently say "3 days", so I'm guessing it ends at the last minute of Jan 31? I'm currently sending out a newsletter to our list encouraging people to vote. Our list size is unfortunately pretty small (we don't have many newsletters, since our community is here), but I suppose everything helps.

Those are already being run through the __('translation'). But note that the translations only apply if they haven't been overridden by the page titles themselves. If you are using a multi-language 'title' field, that takes precedence because you've essentially told it "I am providing the title translations". This would be a good reason for you to set your 'title' field to inherit the default language value when not populated (a setting that appears with each multi-language field). I mention this because I saw an earlier screenshot from you that had nothing in the top nav except for the wrench. I always wondered what was going on there, but now I think I know why: a multi-language title field that isn't falling back to the default language, combined with untranslated admin pages. To correct this, I would just update your 'title' field to inherit from the default language when no translation is available. There should always be tabs for: Site, Core and New. If you guys aren't seeing those, can you check if maybe a Javascript error is occurring? There must be. What file is the error coming from? Of course, try hitting 'refresh' in your browser a couple times, just in case it's a browser cache thing, but I doubt it.

Horst, thanks for that list of timezones–that's what I needed to get this going. Setting the time zone is now in the installer. Manfred62: the translation ability of the admin theme is now ready. It now pulls its translations from /wire/templates-admin/default.php (the old admin theme file) so that's the only file that needs to be translated. Meaning, existing translations should work, for the most part. The old admin theme has also been updated to better support the new jQuery UI version we've got in place. So those wanting to use the old admin theme with the new ProcessWire can continue doing so (like if you need IE8 support or something). The /wire/templates-admin/ directory and files are going to stick around as a place for shared admin theme assets for the purpose of translations and common includes (like debug.inc) or common JS files (like inputfields.js).

I'm not aware of any issues between ProCache and the latest version of dev (or any version of dev). I'm using that combination on three sites here, though on mostly default ProCache settings. What are your ProCache settings, particularly under Behavior and Bypass? When you upgraded your site, what version was it running before? Did you replace the entire /wire/ directory (removing/renaming the old, rather than replacing into the existing /wire/)? Did you replace the /index.php and /.htaccess files with the new versions when doing the PW upgrade? Are you running any PHP opcode cache like APC or eAccelerator? If so, you may need to clear them. To clear an APC cache, you can call a function from PHP: apc_clear_cache();

Following up from the previous message, the update is now committed to dev. I ran a test install, and all appeared to work well (Chrome / OS X). If anyone else gets to test it out in other browsers or platforms, please let me know if you run into any issues. Here's what the color theme selection looks like (screenshot attached) ... basically just a select box that swaps the stylesheet with an onchange event.

Ok I've got the admin colors selection built into the installer now (with live preview even). Installer also now uses the new theme. I ran out if time before I could get it in GitHub (now at my girls' swim practice), so hope to get it committed to dev later today.

Already done

I agree. Everyone please vote if you haven't already. This would be good exposure for ProcessWire. I hope to get an email distribution sent out for those that might not yet know about this, but don't want to send it till the last couple days of the contest (urgency produces better results with those things).

Tested out here and works very well, good results, and was easy to implement. Nice work Philipp!

Soma I'll take a look a closer look at the issue and respond via GitHub soon.

You can also change the admin URL by editing the admin page, switch to "settings" tab and change the page name from there. You'll get a 404 after saving since the URL to the page you are on just changed. But go to your new URL and you should be good.

It's easy enough to change the active user for the current request: $user = $users->get($id); if(!$user->id) throw new Wire404Exception(); if($user->isSuperuser()) throw new Wire404Exception(); $session->setCurrentUser($user); But before you do anything like that, you need to be absolutely certain that the user has no ability to set the $id that gets called in $users->get($id). I think you may have to jump through some security challenges with any kind of solution that logs in a user without a password. So I would really advise against it. Beyond the security issues, the other problem with the code above is that it doesn't keep the user logged in. That's because the $session->login($user, $pass); sets cookies and starts a session. Just setting the $user for the current request does not do that. Since you don't have the password, you'd need to override PW's authentication with your own: $user = $users->get($id); if(!$user->id) throw new Wire404Exception(); if($user->isSuperuser()) throw new Wire404Exception(); $pass = 'some long string that only you can see'; $session->addHookAfter('authenticate', function($event) use($user, $pass) { if($event->return) return; // user already authenticated if($user->name === $event->arguments('name') && $pass === $event->arguments('pass')) { $event->return = true; } }); $user = $session->login($user->name, $pass); if(!$user) throw new Wire404Exception(); I've not tested this out, but in theory is should work. But again be really careful about this, as I think you may be creating a security hole in bypassing the regular login process.

This is not intended behavior. Good call. It's happening because the TemplateFile class is checking if the file it's given exists from the constructor rather than from the render() method. The PageRender module gets a copy of the TemplateFile instance from the Page, and then changes the filename if you've given if one. As a result I think I can solve this just by moving the "file does not exist" exception out of the TemplateFile constructor and to the render() method. I've just made the change, so it should appear in the next batch of commits to dev.

Thanks Manfred62, I have added these and will post them in the next batch of commits. I don't know why the PageRender.module one wouldn't be translatable--it should be. The variables needed to be abstracted out of the string with sprintf, which I have done. That may be what the issue was.

Adrian, thanks for these updates. Are you going to be updating the GitHub repo for these changes as well?

Double check that you are running the latest version of the MapMarker Fieldtype. Go to your map field settings (Setup > Fields) and see if you've got default coordinates defined. Hit save on this page, just to make sure everything is committed to the DB (perhaps something was left out before). Now try editing your page again to see if you can delete the coordinates. If you are still getting an error message, try switching out two things just for testing purpose: try it in Chrome (rather than FF), and try using the default admin theme. I suspect it's not the admin theme, but just good to rule things out. Lastly, if you aren't on the dev branch, try switching to it. Please let me know if you find any of these to change or resolve the issue. However, the actual error message you got about being unable to geocode the address seems to indicate that it still can't connect to Google for one reason or another.. but that would probably be an issue separate from being able to delete the coordinates. Still, you may want to double check from a phpinfo(); that allow_url_fopen really is active in your PHP (you do not need to enable allow_url_include, nor do I recommend it).

I don't think that you could get two instances of ProcessWire running from the same PHP script. Perhaps that's something we should work towards for the future (and we really aren't far from it), but currently the convenience and simplicity of being able to use functions like wire('api var'); among others, takes precedence over true isolation of the ProcessWire instance. While I've not tried it, I'm pretty sure this would prevent you from having more than one PW instance operating from the same PHP script. You would need your multiple PW instances to use more traditional web service communication.

Hanna Code doesn't actually execute from the DB. It writes each Hanna code to a file in /site/assets/cache/HannaCode/ and then uses the DB copy of the code to compare against the one on the file system, to make sure something hasn't changed the one on the file system. It executes the PHP code from a file in order to ensure it is as fast as possible (avoiding eval) and in the same context as a template file. That's what it does behind the scenes, but Soma's tip is just as useful either way, as Hanna Code wouldn't let you edit its own PHP files directly.

Debbie, if you want to PM me the login information to the server I can take a look at it, to at least diagnose what the issue is.

ProcessWire will automatically remove stop words from a query that's going to use a fulltext index. However, it doesn't know what your MySQL ft_min_word_len might be (minimum indexed word length). So in this case I think the issue is the 3 character word "day", when the ft_min_word_len is 4. Marty in your case I would just change the search operator from "~=" to "%=". Either that, or you could have run a second query that uses "%=" if the first fails to match any results (this would probably be better).

Is this question specific to the AdminCustomPages module or specific to the admin theme in the PW dev branch? If admin theme in dev branch, you can remove or rename whatever theme you have in /site/templates-admin/. Then go to Admin > Modules > Core > Default Admin Theme and click "install".

Have a look in /wire/modules/PageRender.module. If you find it would be helpful to have any of those methods hookable that aren't already, let me know and we can do that. We've also got /wire/core/CacheFile.php which we may be able to modify to inject a file system dependency or make parts of it hookable. The way that I implemented caching with ProCache was to just make it something completely separate from the template caching, though not sure that would be the right route for your needs or not. But this route involves hooking after Page::render() and saving the result to a file.

When the file is protected, it's getting delivered by ProcessWire rather than Apache. ProcessWire doesn't know about all the different possibilities for file mime types, so it defaults to sending it as a binary download. Meaning, your browser should save it rather than display it. Though my browser still seems to recognize and display PDFs regardless, so the behavior may vary depending on the client side.

PW is looking at the request URL. Since your request URL is /5gum/, PW thinks that's the starting point. You may need to set $config->urls->root manually to /admin/. This bit of code is probably not so safe: $brand_slug = basename ($_SERVER['REQUEST_URI']); // this would get me "5gum" $brand = wire('pages')->get("name=".$brand_slug); // this gives me a specific page I'd suggest changing it to: // sanitize brand slug with the pageName function $brand_slug = wire('sanitizer')->pageName(basename($_SERVER['REQUEST_URI'])); // this would get me "5gum" $brand = wire('pages')->get("name=$brand_slug"); // this gives me a specific page // double check that brand is what you expect and that it's viewable if(!$brand->id || $brand->template != 'brand' || !$brand->viewable()) throw new Wire404Exception();

When you get that error message "call to member function size()", what is 'images' ? Is it NULL or is it a single image field that has become a multi-image field? To tell, you could try doing a var_dump() on it or this: $images = $pers->lang_image->first()->images; echo "images is: "; if(is_null($images)) echo "NULL"; else if(is_object($images)) echo get_class($images); else var_dump(images); If it turns out that it's null, then I'd be curious what the first() is returning to you. You could run the same code on that result. We know it's got to be an object since the error occurred on the size() call and not on images. $first = $pers->lang_image->first(); echo "first is: " . get_class($first); Please let me know what you find?