Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/25/2023 in all areas

  1. This week in the blog we’ll look at the new WireSitemapXML module, a new WireNumberTools core class, and a new ability for Fieldtype modules to specify useful ready-to-use configurations when creating new fields— https://processwire.com/blog/posts/pw-3.0.213/
    8 points
  2. While @gunter's wording is maybe not the nicest (!, !!, !!!) I understand and also think that having markup regions in the blank profile is not a good idea. For someone not familiar with markup regions (or PW in general) that's an additional step to take and an additional thing to understand. It might be obvious for us, but I doubt it's obvious for many newcomers. I've realised that when working on the video about RockFrontend (https://youtu.be/7CoIj--u4ps?t=78). I'd much more prefer if the blank profile would really be a blank profile. Without markup regions. Just plain PHP. With all the tools waiting for you if you want them, but not forcing you to use them in the beginning. You can read about the background here: https://processwire.com/blog/posts/starting-with-the-blank-profile/
    3 points
  3. You always get normal delayed output out of the box, even if $config->useMarkupRegions is set to true by default. Markup Regions is never enforced, and even though it is turned on by default it just sits there to be used. If you do not need it, you can disable it for performance reasons, of course.
    2 points
  4. This week we have a new core version available on the dev branch. Relative to the previous version, 3.0.212 contains 32 commits, 16 issue fixes and 3 PRs. Here's a list of what's been added: Improvements were made to InputfieldImage so that you can now add your own image actions with hooks. More details in this post and ProcessWire Weekly #455. Significant refactoring and improvements were made to the ProcessPageEditLink module. One of the most notable is that it now will retain HTML class attributes on links, even if not specifically configured with the ProcessPageEditLink module. This is useful if you've added custom classes for links in TinyMCE or CKEditor, but haven't also added them to the ProcessPageEditLink module configuration. Improvements were made to Text fields so that HTML Entity Encoder is now automatically added. This was covered in detail in last week's post and in ProcessWire Weekly #457. InputfieldEmail has been updated with optional support for IDN emails and UTF-8 local-part emails, per request. Two new $sanitizer methods have been added: htmlClass() and htmlClasses(). These sanitize HTML class attributes, and it's part of what enables us to support the custom class attribute support added in the ProcessPageEditLink updates mentioned above. Added feature request #480 to support configurable file extensions for translatable files (beyond .php, .module and .inc). Added a new uploadName() method/property to Pagefile/Pageimage objects that returns the original unsanitized filename as it was uploaded. Applies only to files uploaded since this feature was added. Be aware the filename is unsanitized so be careful with it. This was to partially answer feature request #56 and this solution was suggested by Bernhard Baumrock. Demonstrating the above, InputfieldFile now shows this original filename if you hover the file icon, and InputfieldImage shows it if you hover the current filename. HTTP requests that contain an accidental double slash in the URL now redirect rather than render the page. The PagesParents class was refactored so that it is now a lot faster in saving its data to the pages_parents table. This is very noticeable if you have a site with more than million pages when changing the parent of existing pages, especially those having children. Previously there was a [potentially very] long delay at large scale, now it is instant. More details on these updates, and additional updates can also be found in ProcessWire Weekly #455, #456 and #457. Thanks for reading and have a great weekend!
    1 point
  5. Thanks. To get the width and height of an image, I'm doing this: // within repeater loop that has a file field called 'project_file' $imageSizer = new ImageSizer($project_file->filename); $width = $imageSizer->getWidth(); $height = $imageSizer->getHeight();
    1 point
  6. I have to stop a day early to leave town for one of my daughter's gymnastics meets, so I'm going to save the core version bump for next week, after a few more updates. The most interesting core update this week is one suggested by Netcarver and Pete. It is to make the "HTML Entity Encoder" Textformatter option (for text fields) more foolproof, by making it harder to ignore. That's because this option is rather important for the quality assurance and security of your site's output. If you forget to enable it for one text field or another, then you allow for the potential of HTML in the output for that field, by anyone that can edit pages using that field. Most of the time when you aren't entity-encoding output, HTML is exactly what you want, such as with TinyMCE or CKEditor fields. HTML entity encoding is necessary when the field value isn't itself HTML, but will eventually be used in HTML output and needs to be valid for HTML output. Think of a "title" field, for example. For these cases, you want to be sure that characters like greater than, less than, ampersand and single/double quotes are properly encoded. Greater-than and less-than characters form HTML tags like <script>alert("gotcha!")</script>, ampersands begin entity sequences, and quotes are used to open and close HTML attribute values. By entity encoding all of these characters, we ensure they can't be used for malfeasance, scripts, XSS, defacement, etc. The worst case scenario would be that you neglect to enable the entity encoding on a text field where you are allowing non-trusted user input, as that could open the door to such shenanigans. To make things more foolproof, ProcessWire now gets in your face a bit more about using the HTML Entity Encoder. Maybe it's a bit more annoying for more experienced users, but if you happen to be in a rush, it'll make sure you at least don't forget about it. Or maybe some less experienced developers might not know the importance of entity encoding in HTML, and this update helps them too. Here's what it does: It now enables the HTML Entity Encoder (Textformatter) for all newly created text fields (and derived field types). Previously it just suggested that you enable it, but let you decide whether or not it was appropriate. Now, it errs more on the side of caution. Since the entity encoder is now automatically enabled for newly created text fields (in the admin), it seemed necessary to detect cases where the field configuration clearly indicates it's intended to allow HTML (by input type or content-type). Examples include textarea fields configured to use TinyMCE or CKEditor, or any text field with a content-type set to HTML. When these cases are detected, it advises the user to remove the HTML Entity Encoder from the selected Textformatters. If editing an existing text field (in Setup > Fields) that doesn't appear intended to use HTML (i.e. not TinyMCE or CKEditor and doesn't have its Content-Type set to HTML), it will now test all the selected Textformatters you have selected (if any) and see how they handle HTML. If they leave HTML in place, or you have no Textformatters selected, It will provide a warning to you, letting you know that HTML is allowed, and leave it up you to decide whether that's what you want. Note that these additions are only for fields created in the admin. Fields created from the API make no such assumptions and work the same as before. That's it for this week. More updates and hopefully a version bump next week. Have a great weekend!
    1 point
  7. When adding/saving Repeater items the sort order is determined by the "sort" value of each Repeater page, not by any order you might apply to the Repeater PageArray. An explanation of sort values is here. You could use the $pages->sort() method to set the sort value of the Repeater page you're adding and it will automatically update the sort values of the sibling Repeater pages. $thatPage->of( false ); $newItem = $thatPage->my_repeater->getNew(); $newItem->foo = 'bar'; $newItem->save(); $thatPage=>my_repeater->add( $newItem ); $thatPage->save(); // Set the sort value of the new item to 0 and adjust sibling sort values $pages->sort($newItem, 0);
    1 point
×
×
  • Create New...