ryan

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

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.