ryan

When I need a calculated field that will be used for sorting, I like to add a hidden (or regular, doesn't matter) field to the template to store the calculated value. The value gets automatically calculated on page save. A hook like this in your /site/templates/admin.php can do the work for you: $pages->addHook('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); if($page->template == 'rider') { $miles = 0; foreach($page->rides as $ride) { $miles += $ride->miles; } $page->miles_ridden = $miles; } }); Then when it comes to sorting, you just sort on your calculated field: miles_ridden. If you are adding this to an existing PW installation, then you'd need to establish the initial values for each rider's miles_ridden. This could be done with a quick bootstrapped script: /setup-riders.php <pre><?php include("./index.php"); foreach(wire("pages")->find("template=rider") as $rider) { $rider->save(); echo "$rider->name: $rider->miles_ridden miles ridden\n"; } Then you'd just load domain.com/setup-riders.php in your web browser, and then delete the file when done.

You can make up your own users system, and sometimes it's the simplest route to achieve something. But I would try to get it done with regular PW users first. You can always map fictional page names to usernames via URL segments. For instance, if you had a template called 'riders' and you enabled 'URL segments' in the 'URLs' tab of your template, then your /site/templates/riders.php file could have code like this: if($input->urlSegment1) { $rider = $users->get("name=$input->urlSegment1"); if(!$rider->id || !$rider->hasRole("rider")) throw new Wire404Exception("Unknown rider"); // display rider echo "<h1>$rider->name</h1>"; echo $rider->body; // ...or whatever fields you wanted to output } else { // display list of riders foreach($users as $rider) { if(!$rider->hasRole("rider")) continue; echo "<li><a href='./$rider->name/'>$rider->name</a></li>"; } }

Regarding the first part of your question: if you want PW to run from the root of your domain, it's best to install it in the root so that you have /index.php, /wire/ and /site/, and not /subfolder/index.php, /subfolder/wire/, and /subfolder/site/. I'm glad you found a rewrite rule that works in your case, but I'm not confident that PW will be totally happy with it as it does consider various server variables to determine the installed path–page URLs might still reflect the subfolder. I don't totally understand the question. But if you need to ZIP up a copy of a site, then you only need to create a ZIP of the /site/ folder. Everything else (which is just index.php, .htaccess, and /wire/) can be obtained with a fresh copy of PW. When I'm backing up sites, I usually just backup the /site/ folder since I know everything else can be easily obtained.

Landitus, you and Soma are talking about two different issues. The issue you mentioned, about the description (alt tag) disappearing after editing an image, is one that I can't duplicate here (just tried). You may want to upgrade your site to PW 2.4 just in case the version you have had some issue in that regard. The issue that Soma mentioned is an expected one, because when you use the link or image dialogs, it is writing out a new <a> or <img> tag when you click the "insert link" or "insert image" button. Since a 'class' attribute is not used by the link dialog, it writes out a new <a> tag with no class attribute.

Joe, to re-create PW's javascript 'config' variable on your front end, you could just duplicate what's being output by this function. There's not much to it. To ensure that all the right JS and CSS files get loaded you only need to do this: foreach(wire('config')->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach(wire('config')->scripts as $url) echo "<script src='$url'></script>"; Also for anyone else reading, this has nothing to do with CKEditor. This is just generally how you'd duplicate PW's admin vars/styles/scripts on the front end.

I don't think it matters. I've had similar situations in the past but never had issues. I've even had tables that were the wrong character set, but storing UTF8 (a long time ago) and it didn't become a problem until I needed to export and import somewhere else. But if your tables are already the right character set, then I don't think you've got anything to worry about (someone correct me if I'm wrong). You might notice that PW uses the ASCII character set in MySQL for some fields (like those storing 'name' format data, where nothing beyond ASCII is needed).

Good point Adrian. I've added 2.4, and also updated all the modules that are compatible with 2.3 to also indicate compatibility with 2.4. I think this is reasonably safe to assume (I haven't yet found any modules that aren't compatible with 2.4). I made a little bootstrapped script to do it for me… these are always fun ways to feel like you got some work done in 5 mins. include('./index.php'); $v24 = wire('pages')->get('/versions/2.4/'); foreach(wire('pages')->find("pw_versions=/versions/2.3/") as $item) { $item->pw_versions->add($v24); $item->save('pw_versions', array('quiet' => true)); echo $item->title . "<br>"; } If anyone comes across any modules that they find not to be compatible with 2.4, please let me know so that I can update the directory.

Thanks ceberlin! This is just a soft launch of 2.4, as I've still got some items to cover before telling everyone about it. However, I was feeling that 2.4 is already a lot better and more stable than 2.3, and that there's just no reason to have people download 2.3 anymore. So 2.4 is now the stable version, but it will still be getting some minor incremental updates for a little while. For those upgrading, be sure to read the upgrade instructions and additional upgrade notes.

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.