ryan

Adrian, what about just using the Pagefile::rename function from a hook after Pagefile::install ? I may not be understanding the issue in full. But couldn't you just do something like this: public function hookAfterPagefileInstall($event) { $pagefile = $event->object; $pagefile->rename('filename.' . $pagefile->ext); }

Looks like you've got an incomplete/corrupted debug.inc file? I would download a fresh /wire/ and replace it entirely if you can, just in case there are any other truncated files in the core.

The debug info is meant to be shared among admin themes (optional), so the new admin theme uses the one from /wire/templates-admin/debug.inc. Have a look in that file. At the bottom should be a Javascript section with a $('#debug').accordion(...). It sounds like that JS is not getting executed or, maybe there's another element on the page with the #debug id? We should probably use a different ID attribute for this debug div, as #debug is a potentially very common thing that is maybe best left for 3rd party use. If you view the source on your page and search for "debug" does it come up anywhere other than for the <div id='debug'> at the bottom? That just means that the files for that module aren't writable to ProcessWire. The logo is intended to disappear at mobile sizes. But if the combination of topnav items + search boxes forces them to be split on two rows, then it'll show the logo again, since there is room for it. If the combination forces it to go onto 3 lines, then it again hides the logo and moves all the navigation to that hamburger icon. So the behaviors kind of depend on how many top navigation items you have in your admin. Thanks, I'll go through and test these out and add any missing __('functions');

Thanks, that helped me to fix it (I think!). If you try out the latest dev, you should now see a Core tab (file updated was this one). Please let me know if that doesn't resolve it. The attributes you mentioned are added by jQuery UI via Javascript. Check if there is a JS error occurring? I don't know what "New Admin Theme" is, but check your /site/modules/ directory to see if you've got an admin theme in there and remove it if you do. Also if you've got a /site/templates-admin/, go ahead and remove or rename that too. Double check that your /wire/ directory was fully removed and replaced (rather than replaced into) during the last update.

Thanks for testing it out. Can you give me an example of one of those paths it outputs? I was worried that might have implications, so tested it pretty thoroughly before committing just to be safe. Just out of curiosity, why does that break Fredi? The benefit of moving that to be inline is that the tabs appear faster and with less jump. It only makes a difference on big/complex edit forms (I'm working with a couple here that have 1,000+ inputs).

You reported WireTabs not working in modal=1 mode on GitHub, but I've not been able to reproduce that. There was an issue a couple weeks ago with modal=1 mode, but that was fixed. It's possible the version you upgraded to (2.3.13) didn't that that fix. We are now at 2.3.15. Debugging is developing I'm not aware of any changes that would affect access control, though we do have bug fixes in place. Most likely your site was affected by a bug involving the rewriting of the pages_access table, and when you saved something with the roles, it dumped and re-created the table, cleaning out the old buggy data.

Kongondo and/or Sinnut: could you guys try this script. Put it in your site root and then load in your browser: /test.php <pre><?php include("./index.php"); // bootstrap PW wire('config')->debug = true; foreach(wire('modules') as $name => $module) { try { $reflector = new ReflectionClass($name); echo "\n$name => " . $reflector->getFileName(); } catch(Exception $e) { echo $e->getMessage(); } } it should output a list of all modules and the files they come from. But I'm guessing you guys will instead see an error message. What does the error say?

I'm lost as to what could be the issue with the missing Core tab. How do you guys install core modules if there is no Core tab? Do those modules appear on the Site tab? If not, try viewing the source and search for "Autocomplete". See if the InputfieldAutocomplete (a core module) is showing up anywhere in the source? This should help us to determine if this is a PHP problem or a front/end CSS/JS problem.

Great to see lots of new votes and tweets coming in. Thanks to everyone that's been voting and tweeting–keep it up! If you haven't yet voted, now is a good time to get your vote in as we've got just 2 days left.

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).