ryan

I found out this week that Google still has the "basic" calendar feed open. We know the "full" calendar feed has been gone since November, and I hadn't read anything about any of them still being open. So I have no idea if the basic one was re-opened, or if it's always been open, but it's there and fully accessible. Maybe this is common knowledge, but it's news to me–I found out about it just experimenting with Google's URLs. It's a much bigger pain to pull the data from than the "full" one since most of the data is not structured, so it has to be parsed out with regular expressions. But I went ahead and updated this module to support the basic feed, as it has all the data that we need in it. It's now ready to use in the latest update (v2.0.0). It looks like the "basic" feed also accepts all of our date and keyword queries too, which is great. As far as I can tell, it returns this module to a fully functional state with all features working once again. I'm guessing that because we have to parse the data with regex's that much of it may not translate to Google calendars in other languages than English, so that's something to be aware of. But if anyone comes across any examples I can always see what might be necessary to add support.

I've been looking for a fix for this, thanks! Just tested locally and seems to work nicely. I will update the other modals as well.

Yes this is default enabled on all image fields. I don't see any reason to have it disabled. Comments manager is only in the core dev branch. Once that becomes the new master, I'll likely remove the latest comments module from the directory. No plans to integrate at present. The crop feature added here is something entirely different from CroppableImage, and predefined crops are really the specialty of CroppableImage, which does a great job of it. The crop feature added to the core is more about getting the main/source image right, like for clients that don't have any image editing tools on their computer. It's particularly helpful in having some control over whatever variations might be created on the front-end of your site. For example: we are building a company directory and people upload various sizes of images for different people and sometimes people's heads get cut off in some variations. I'm using a square thumbnail on the listing page, and client uploads a tall portrait image. Head gets chopped off on the square thumbnail. Now the client can see "oh there's a problem there" and fix it themselves rather than calling me. That likewise fixes it for any other variations that might be generated from the same source image. No accounting for any of this is necessary in the site's code. Now I could use CroppableImage too, but I don't need this level of control for most of the images in the scenario I described, and don't want to make any changes to my site's front-end code to support it. Just want to give the client the ability to fix their own problem images when they pop up. Not looking to replace CroppableImage, which is already awesome and a great tool to use when your need calls for predefined crops.

That's just part of the stylesheet in AdminThemeReno. It doesn't do that in AdminThemeDefault. We can ask Renobird about maybe changing it. I don't mind the uppercase myself, but it does seem maybe a little large when it's displaying anything other than a short title. It wasn't coded to retain align classes through cropping, but I suppose it could. I'll look into it. That was actually fixed about an hour ago (https://github.com/ryancramerdesign/ProcessWire/commit/bdf74054b3da06b1b354189381ed8c2f191b857a). I'd never seen it myself till I uploaded this version to a client site and tested it out, and then suddenly got that error for the first time. Getting those plugin.js files out of your browser cache can be a pain though. You may have to clear your cache or quit/reopen the browser. Just tested and it doesn't. Looks like CroppableImage overrides the methods where this stuff is generated in InputfieldImage. However, it would likely be as easy as Horst just adding a single edit link to the output of CroppableImage.

The other half of the images update is now in place on the dev branch. This enables you to edit images directly from the images list that you see when editing a page. When you hover an image or image thumbnail, you'll now see an edit icon appear in the upper left corner of the image. Click it and a modal opens. From there you can crop and resize, and replace the original image, or save it out to an entirely new image (copy). When cropping and then replacing an image, it will also attempt to re-create any size variations to reflect the new crop. This update also includes tweaks and improvements to what was posted last week. I'll cover this all in more detail in Friday's blog post, likely with a short screencast too. But wanted to go ahead and mention that it's there now if anyone is interested in testing it out. If you do test it out, do a Modules > Refresh in your admin after installing the latest dev version. This will make it update the versioned JS/CSS links to ensure your browser isn't still serving older versions. Though sometimes it still takes quitting/reopening the browser or clearing the browser cache. Please let me know how it works out for you.

Actually they can place the images anywhere they want to in the text. They aren't limited to just placing it at the top. Of course, when you find where you want to place the image in the text, then at that point you have to specify whether its an image that should be left aligned, right aligned, or centered. On the front-end, you can choose how you want to handle that. While most of the time the text floats around it, sometimes I'll take an alignment and make it pull into a blank left/right column. Images for predefined placement in a layout shouldn't go in the text at all. You'd want to have a dedicated field or tag for those images. If there are more than a couple predefined placements, I might use tags so that an image with the tag "hero" automatically goes to your dedicated hero spot, etc. I usually treat galleries as predefined placements (like appearing above or below the main content). Rarely does the need arise where galleries need to be part of the actual copy, but others may have a different need/experience, so I think that's a good example. While I like having a consistent placement for a major feature like that, it's really more about having markup that is generated dynamically when the page is viewed. But if you wanted the ability to place galleries of images in-between blocks of copy, then I agree that's a good use case for a block editor. Whether it's worth the compromise would depend on the need I suppose. Perhaps that's a great case for a hybrid editor that is primarily RTE but provides certain blocks you can work with. CKEditor does actually provide something called Widgets that allow insertion of more complex predefined markup elements, but I don't think it's quite there enough to where I'd want to use it for a gallery. That's because it's something I'd want to generate on the front-end rather than directly in the RTE-generated markup. I don't like RTE's generating anything other than basic markup because it's just not as portable... once you start using CKE widgets, you can't really switch to another RTE without losing those widgets. Probably what would be ideal is CKEditor with a block-editor style select input at the bottom that lets you add certain types of elements like galleries, paginations, or other things (but not simple markup elements like headlines), and then lets you continue the text content underneath in another CKE instance. That would let the RTE do what it's good at, and let blocks handle the things that would benefit from having their markup generated at runtime (like a gallery).

This was also part of the update, but not yet finished. It'll be finished in this week's update. If you want a preview of what it does, you can click on the filename of any image (currently hidden that way, since it's not yet fully functional). It'll let you size and crop it just like in the RTE version, and then give you the option to replace the original or save as a new copy. But if you try it, no need to send issue reports just yet because it's only a work in progress at this point (the code just isn't there yet). Btw, it's not a replacement for CroppableImage, so if you have that need, you'll still want to use CroppableImage. The tool being added is purely about manipulating the base images in the image field, not about creating predefined/named variations to pull on the front-end. Though manipulating the base image may be exactly what you need to keep your api-generated variations from copping off someone's head, etc

The problem I have with SirTrevor and other similar projects I've seen are that the actual editor experience just isn't as good. It feels downright unnatural relative to anywhere else one might edit text. When I experiment with SirTrevor and others, I can't convince myself I'd want to use it on my own site. And if I can't convince myself, I won't be able to convince my clients to use it. How would you like it if we switched to SirTrevor for the editor in these forums? I think we'd have a lot less activity. There is an assumption with these tools that the end user is actually authoring the content directly in the editor. That's what I do most of the time, but most of my clients author content offline or work with existing content created by somebody else. Basically they are pasting content and often lots of it. These block editors become an especially huge pain when you are doing that. Many other types of edits just become unnatural and clumsy. It's not about the implementation of the block editor being faulty in anyway, its just that the entire concept doesn't result in a better editing experience. Where I like the block editors is that it's less to accommodate and worry about on the front-end development side. It also opens up some other kinds of element placements and previews that would be difficult with a regular RTE. So I totally agree there is a place for these editors. But I don't think we'll ever see RTEs replaced entirely by block editors, no matter how good the implementation is. Though I'm sure we'll see some good hybrids.

Absolutely, I consider it essential. Placement of images is one of many reasons to use an RTE, but it's a big one. Our tools were somewhat lacking in this area before, and that may have even been a reason not to use them. CKEditor is perhaps the Inputfield that our (or at least my) clients interact with the most in PW, and I'm committed to making sure the tools we provide in this area are the absolute best they can be, as with all areas of ProcessWire. That doesn't mean you have to use all the features an RTE provides. In fact, I rarely recommend doing that. You may find some features suitable for some situations more than others, and you have control in your field settings to determine what is available. There are some site designs I work with where I'll turn off the ability to insert images at all (or even turn off the RTE all together). But there are also plenty of site designs I work with where that ability is very important to the client or the needs of the site. One of ProcessWire's key benefits is not pushing assumptions about the front-end, or pigeonholing the software into some specific types of sites. We're trying to accommodate a diverse range of needs, not just specific ones. We accommodate specific needs with configuration. We've always provided image placement capability in our RTE, but with limited ability to manipulate the image beyond just resizing it. I've been looking to make this part better for a long time for the needs that I see with my own clients. That's what the first paragraph of the blog post was trying to explain. Beyond that is selling PW itself. It's one of those things that users look at when evaluating a CMS. Regardless of what you may think about RTEs in general, lack of RTE is a deal killer for many/most, and how good the RTE and related tools are is a seller. Look at WordPress, which is limited relative to PW in so many ways, but their tools like the one discussed here have always been significantly better than ours. ProcessWire has very little in common with WordPress, but when compared side by side for editing features, things like this make WordPress look better to the casual evaluation. This is one reason why you see WordPress used in so many inappropriate scenarios. So when it comes to tools that we provide already, I want to make sure they are the best they can be, and not just half way. That has not been my experience. I have had clients mess up things in RTEs, but rarely related to images. It's usually about typography, so I like to introduce limitations about what markup elements the client can use, particularly headlines. CKEditor with ACF and Purifier enabled has also solved the vast majority of clients-messing-things-up issues I've had in the past. Maybe your experiences are different, but these are the problems with images that I've seen with my clients: It's nearly always about poor image selection, not placement. By that, I mean the client will upload really bad stock imagery of business people on 1990s cellphones and such. This issue has nothing to do with an RTE, and is an issue anywhere the client can upload images. Clients rarely have the image tools [on their own computer] necessary to prep their image before uploading. They've not had a way to crop images to make them right for the context. For instance, needing to show a picture of a specific person but instead having only a photo with a group of people, and using anyway. Though this update does solve that problem among other things. I understand there are site designs where you want limit what the client can do with images, or maybe you want to prevent them being able to place images in text at all, leaving that for your own code to handle. This lets you have more control over the resulting layout. I get that, and I work on plenty of those too. But understand that this is a specific need in some layouts, not a universal need in every site or design. The same goes for use of an RTE at all. There are plenty of situations where entity encoded plain text or an LML like Markdown or Textile is more appropriate. But for situations where an RTE with image placement capability is the appropriate tool, I want it to be as good as it can be. This is a tool we already have, and so this update was about enhancing that tool to make it better for its intended purpose.

@OllieMackJames my advice would be to use the dev branch for new projects, and the master branch for existing projects. Though I mostly use the dev branch for both. If you use the dev branch on a production site, you just want to make sure it's one that you keep track of and can report any issues if/when you see them. The current dev branch actually has a lot of bug fixes from 2.5.3, so it may technically be more stable in many ways. However, it also contains a lot of new features and code that doesn't yet have as much mileage on it.

Another Friday blog post with core updates just posted. This time we've got several image editing updates, particularly with regard to image editing for images placed in rich text fields. Also included are HiDPI/Retina support, an image variation tool, and more… Read all about it here, plus a video and screenshots: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

Christophe, glad you are enjoying ProcessWire. There are a common set of properties available to all Inputfields, and then there are properties unique to each of them. One of the simplest ways to find those properties is to look at the @property tags at the top of the module file. Not all modules have these yet, but we're working on having them all in for PW 2.6. Here are the properties (link) common to all Inputfields, which you can see at the top of Inputfield.php. Another way to identify properties unique to an Inputfield is to make sure you've got debug mode on (in your /site/config.php file) and then go and edit any field in Setup > Fields, that happens to use the Inputfield you are interested in. Click on the "Input" tab, and you'll generally see most of the custom properties configurable from there. Hover over the little caret symbol to the far right of the field, and the API property name will reveal itself in the field label. LostKobrakai is also correct that Inputfield modules are originally intended more for admin and module use rather than front-end site use (since PW is mostly not involved in markup generation for front-end). But as more people begin to use these modules in new ways, we'll likewise try to make documentation about them more accessible.

New dev branch updates for this week: Field editor now lets you target templates Optimization to field cloning Live-updated session viewing tool Session cleanup on certain Debian-based servers Configurable session fingerprints Session history from the API

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