ryan

Categories are really a perfect use case for pages rather than options. But to answer your question, this should do it: $options = $fieldtypes->get('FieldtypeOptions')->getOptions('categories'); foreach($options as $option) { echo $option->title; } This also works: $field = $fields->get('categories'); $options = $field->type->getOptions($field); If you are going to be using the selections for anything, use the $option->id property, rather than the title, just in case you later go back and change the title or something.

Glad you like it Alan. For some more fun, keep one of those often-updated log files open in your browser, and watch it update automatically to show you the new log entries every time something gets added to it.

Just tested but seems to be installing normally here. Are you sure you have the main LanguageSupport module installed? that's a pre-requisite or all the modules you listed. You might also try a Modules > Refresh, just in case the cache needs a clear.

Since we're dealing with coordinates that don't change, it would guess that something is manipulating this at the CSS level so that the markers are getting offset. Especially if you are not seeing the same offset in the admin preview of your marker. The best bet may be to isolate and test it in an environment outside of any particular site (no other CSS or JS other than what comes with MapMarker and Google), and then slowly add your other files back to narrow in on what is causing the apparent 100-pixel (?) offset to the left. I'd also suggest trying another browser, just in case.

This week's dev branch updates include a new Fieldtype (FieldtypeOptions): https://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/ (blog post about it) and documentation https://processwire.com/api/modules/select-options-fieldtype/

This techwars stuff drives me a little nuts because we're not "at war" or in "a fight" with anybody, as they imply. The other CMS projects are our peers not our enemies. Though I understand, wars and fights are controversial and thus marketable. Techwars on Twitter has been spamming the #processwire hashtag for several months. I like to occasionally search for ProcessWire on Twitter to see what's up there, and you can't search for ProcessWire without getting 80% techwars tweets… All implying we're in all of these fights, skirmishes, duels and bloody battles to the death with modx, silverstripe, expression engine, etc. Their average tweet count per day is 1075 (all appear to be the same auto-generated tweet with different product names substituted). I just don't like that people searching for ProcessWire on Twitter might be getting the wrong impression, like we're not friendly or something. That being said, I love the comments that you guys added to their site. If there is a battle at the techwars site, ProcessWire is winning it.

I think "retina" is just Apple's marketing name for what is actually HiDPI? Maybe it would be good to have a $pia->hidpi() as an alias too?

I'm a mac chrome user here, but haven't ever seen that. I'll keep an eye out though.

@GuruMeditation if you are looking for the simplest possible solution, your best bet is to hide the fields you don't want displayed to users with CSS: .CommentFormCite, .CommentFormEmail { display: none; } If you want to go further than that, then you might be better off copying the comments modules to your /site/modules/ and modifying them as you see fit. The comments form is isolated to its own class, called CommentsForm, which you can extend or modify directly. In order to only display the comments form if the user is logged in, you would just wrap the renderForm() call around a conditional that checks if the user is logged in. // render comments list echo $page->comments->render(); // render comments form only if user is logged in if($user->isLoggedin()) echo $page->comments->renderForm();

Joss, glad that did it! Here's why it caused the error: Cookies are set in the http headers. When PHP sends output before the http headers (as would be the case if you had characters before an opening PHP tag) then it wouldn't be possible to set cookies. The result is that it wasn't able to set the CSRF cookie, so when it went to check if there was a valid CSRF cookie there wasn't, making it think it was forged.

Joss, what's on config.php line 1? That's an unusual error to see there. I would guess that when the files were uploaded the encoding got changed somehow? Though double check that you don't have some whitespace prepended in your config.php file. Make sure the first thing in it is a <?php with nothing before it. But if everything looks normal, I would guess that when you uploaded the files something got changed. If they got FTP'd in as ascii, try putting them in as binary. Also, for a quick fix, turn off CSRF protection in your /site/config.php file: $config->protectCSRF = false; But i have a feeling that something might be up with the file encoding, which would cause other problems even if you get the CSRF one fixed.

Merry Christmas! from Atlanta, GA, USA

Looks like they've completely changed it to the point where this module would have to be largely re-written. I'm looking into that. Is anyone already familiar with API v3 of Calendar?

There aren't any connections to the admin theme with this module. But installing AdminThemeReno would have cleared the modules cache, so I'm thinking that's most likely what was needed (a modules refresh). It will go into the core once I can add the option of FTP/SFTP/FTPS installation as an option for upgrading/installing modules and core. Your statement is true with Drumlapress, but not with ProcessWire as far as we know. While newer core versions add new security enhancements and such, running an older version of PW doesn't mean your site isn't safe. If a site is running smoothly and does everything the client wants, I tend to leave it alone. Even if upgrades are relatively safe and easy, there's always a rare chance that something will break and need an update as a result of upgrading the PW core or any module. There are plenty of good reasons to upgrade, but since there are no known security vulnerabilities in past versions as of yet, having a safe site is not currently one of them.

And too bad about WordPress if that's what they are using. I don't think they even know about PW. I will have to have a talk with them sometime.

I used to work there for several years- my first job out of college. I actually designed the website about 2-3 versions before the current one. Though couldn't tell you anything about the current site. I've always missed working there, one of the best places I've worked. Always great to hear about Grafik.

Guys hope you don't mind but this thread is entirely too bizarre, so I'm closing it. There's some good stuff here too, so not going to delete it, but please continue your conversation in a new thread if you want to– just no more name calling, PW death threats or summoning gods. Or if you must, then keep that stuff in the Pub. The general support is not the place for this. -- Edit: just moved this to Pub.

@Chris White, I've replied in the ProFields board.

I'm not so sure about this one because that particular call without an if() statement around it to check if there are any images would be a code error that needs to be fixed. If the error were allowed to continue, the problem might never be fixed. However, if the error were to be suppressed, then it would have to do that by returning some other image. But what image should it return? That should be up to the developer, so we've actually added the option to have it return a default value (image) when no images are present, and this was added specifically for the type situation you describe, where you want image fields to always be "populated" with something even when they aren't. This was added in 2.5 and present on both stable and dev branches and visible on the Image field settings (Setup > Fields). I agree that's a crazy error message that is always a source of confusion. The installer performs all the PHP version checks, but of course if someone moves a site from one server to another and skips the installer, then they might not see the PHP version error message. I'm not sure that PW should be doing a PHP version check on every page load (or maybe it should, have to think about that one a little more). When you saw that particular error message, do you recall where it was originating from (file/line)? If I can isolate the block of code that produced the error, that would be my preference, but if not I suppose a PHP version check on every execution may be necessary.

Nico, I like what you are getting at, but think an option like that might be a source of confusion because it would change the entire way that templates work, as well as the way that viewability is determined. Most likely this would be problematic for PW's internal templates and logic. What I would suggest instead is repurposing of the existing $config->appendTemplateFile option and letting that serve is your defaultTemplateFile. In order to make sure that PW considers your page viewable, you'd still have to have a file for the template, but it could be completely blank. While I'd prefer the method mentioned above, another alternative would be to automatically populate the altFilename property of every template that you wanted to behave this way. For example, in your /site/templates/admin.php file you could add something like this: foreach($templates as $template) { if($template->flags & Template::flagSystem) continue; if($template->filenameExists()) continue; $template->altFilename = 'ajax.php'; $template->save(); }

Languages can't be modules because they are pages, and that's a pretty important aspect of them. Languages are a type of editable content rather code and logic. But it may be possible to have language packs (the translation files) distributed as modules. Language packs are just one component of a Language, but a component that would be useful to behave as a module when it comes to version tracking and installation. I'll look into it.

Didjee, would it be possible for you to try a completely fresh install in another directory? The errors you've mentioned here and in another thread make me think that somehow some old files are present in your copy. Trying out the dev branch would probably be the best bet. I would also be interested to know what your server environment is, beyond PHP and MySQL. Is it running Apache, or something compatible with Apache? Running as a module or CGI/fastcgi?

I've tried to duplicate this one here, but haven't been able to. I've kept the MySQL settings for my dev server at the strictest settings possible for the last month or so, so am thinking that whatever the issue is here, it's probably something different than we've seen elsewhere. Also, so far this is the only report I'm aware of this occurring in the current release version of PW. Since the error is very similar to the one we saw before the MySQL settings issue was fixed, I do wonder if just grabbing a fresh copy of the PW core might be a good idea here. Didjee if you are able to try that, please let me know. You might want to try the dev branch, since that always has the latest updates on it.

Horst, is it possible that the module in question extending FieldtypeImage is overriding its constructor without doing a parent::__construct() ? It doesn't look to be an issue with FieldtypeCropImage, because it doesn't override the __construct(). But you mentioned this is not CropImage, but a fork of it, and the behavior you describe sounds like FieldtypeImage that's being extended is uninitialized (i.e. not having it's constructor called)?

The notifications are part of the admin. PW doesn't get involved with your front-end output, so it's not attempting to provide anything with regard to notifications on the front-end. However, you can still use the API to add notifications to any user, but they'll need to go to the admin before they will see them, unless you provide your own output code on your front-end. If you wanted to output notifications on the front-end of your site, it would actually be as simple as this: foreach($user->notifications as $no) { echo "<p>$no</p>"; } There are of course several other properties, methods and flags that you can access from the Notification ($no) object. But outputting a notification is basically just a matter of iterating through the $user->notifications field and outputting them all, or just the ones you want. So in this sense, it actually would be quite easy to utilize on the front-end, but like with anything in PW on the front-end, you have to decide how you want the output to be handled. Currently it's using the same method as the forum we're typing in (IP.Board). I have not kept up with websockets technology lately, but was under the impression we weren't there yet unless you had specific client-side and server-side libraries to handle it and provide the fallbacks, or were using node.js, etc. I'd gladly implement websockets in the future if they enable us to accomplish the same thing more efficiently, easily and reliably without bloat. Last I researched this, we weren't there yet, at least in our LAMP context. But you likely know more than I do about that technology at this point, so interested in hearing more.