ryan

ProcessWire dev has no DB password requirement, and hasn't for months. Can you post a screenshot or paste in the error that you got? Also adding novalidate as an attribute won't help on the dev installer because the field has no required attribute.

There shouldn't be any deprecated warnings about mysqli at least. We don't plan on dropping that database driver anytime soon, just will encourage people to standardize on PDO in the future after 2.4+ is well established. But I don't really see a reason why we'd ever need to remove the mysqli driver, as some sites may need it for legacy use, even after all modules are using PDO. InputfieldButton only has about 50 lines in it, so not sure about line 253. @ceberlin can you post in a screenshot or copy/paste the exact errors you saw both for the deprecated warning and the InputfieldButton?

I could be wrong but I think those are carried over from the social network votes. Meaning, those 620 votes are probably their combined Facebook, g+1 and Twitter votes, which maybe are allowed to accumulate across contests? There clearly wasn't any gaming going on there though, because they started with 620 votes immediately the first second the contest began. All the other big players there also started with certain quantities before anyone had voted. That's why I think it's carried over from social networks. We do have 1-click module installing already. But we'll setup whatever else they need. I agree, thanks Darren for getting this started! There are a lot of other thanks to go around here too. I for one had kind of given up yesterday when it seemed like there was no legitimate way to win. Then Joss's dog started tweeting and he and others started asking for help from big players like @smashingmag, @modx, etc., and some of us found it very inspiring, among all the other things people were doing. Seeing people work so hard on something becomes contagious. The entire ProcessWire community got involved yesterday, which was fantastic to see whether we won or lost. I looked into their voting system in more detail yesterday after folks had expressed concerns (and after I'd sent that tweet). What I found was that whoever put it together knows what they are doing, unlike most similar voting systems. Their voting system is protected from iframe and/or ajax manipulation, meaning it's unlikely an exploit could take advantage of other users IP addresses without their knowledge (which was the problem with the opensourcecms.com voting system). The only exception would be users on old browsers like IE6 and IE7, but they may be accounting for that in some way I don't know about too. So while you can't accurately log these kinds of exploits, that point may not matter if the exploits are blocked in the first place. Regarding the 50 votes in a minute we may have seen from Ametys, I think the only thing that could produce that kind of result in this case would be if they sent a bulk-mailing to a big list. Social networks would be another way, but they don't have the social network reach to account for those numbers (unless they got a mention from someone else that does). It seems unlikely to me that 50 votes could be faked in a minute in this particular contest. Where the voting system does seem potentially problematic is when it comes to anonymizers (anonymous proxy servers). These are the kinds of services one uses if they might otherwise be blocked from a site due to geography, government, etc. These proxy server sites enable you to browse anonymously, automatically clear cookies, randomize the user agent, change the "location" (and thus IP) you are coming from, sometimes among hundreds or thousands of choices. They mask the identity of the original requester, as they don't pass through the usual headers that would lead you to the original IP. So as someone that has written voting systems similar to Bitnami's, these anonymizers scare me. I personally don't know of any way to account for or log that type of manipulation to votes. Though perhaps they do. The only silver lining in that I'd assume it takes real time, effort and money to use an anonymizer in this way–it's still manual labor, not a script, and probably not worth the effort for someone that wants to make a big dent (not a good way to get 50 votes in a minute). I'm assuming the previously mentioned Tor browser is a front-end to anonymous proxy servers, which falls in a similar scope. I think that a more accurate voting system would use a 1-to-1 mapping system between votes and social accounts from Facebook, g+1 and Twitter. But even that could be manipulated, as users might create numerous social network accounts. However, that's where it starts to take a whole lot more effort from that folks wishing to manipulate results (creating and validating accounts one after the other), increasing the odds of an accurate vote. The downside is that social-network oriented vote competitions are completely dependent upon social networks and it simply doesn't look as good as hosting your own. Not to mention, a certain percentage of very legitimate users avoid these social networks (our social network is our forum, after all). And philosophically, do we really want to hand any more of our keys and responsibilities over to these giant social networks? I prefer to get along without them intruding on everything in the web business. When it gets down to it, there really is no perfect way to handle an online voting system. So I think we need to cut the Bitnami folks some slack, as it does look like they are accounting for everything they can in the environment they have to work with (which is a lot more than most do). While I'd rather they just included the best software and avoided the whole contest thing in the first place... I'm sure the marketing folks want a contest (it's good for business). And if there has to be a contest, then at least they are taking the vote quality seriously.

Congratulations to everyone! We have now officially won as seen on the Bitnami contest page. Thanks for everyone's efforts for this, as this should be a great thing for the ProcessWire project. I'll follow up with more later, but just wanted to thank and congratulate everyone for this community led effort.

Well they said midnight CET. But the votes are still coming in. Hopefully they didn't mean midnight CST.

For you guys in Europe waiting up, word is that the contest ends at midnight CET (10 minutes!)

The workday is coming to an end here, but I think it must be wake-up time in another part of the world using ProcessWire because we're now in 1st place again, getting a good volume of votes. I re-sent our newsletter today with MailChimp because I found out a lot of you guys didn't get it the first time around, so am thinking we're getting some momentum from that too.

Huge thanks to those of you that have been working so hard on this and spreading the word. The support we're seeing here is really awesome, well beyond all dreams. There's only a couple hours left in the contest, but we are currently the closest to them that we've been all day.

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