Jump to content

Leaderboard

Popular Content

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

  1. New version pushed with this.
    2 points
  2. This is a reissue of a module of mine called "PublishingOptions", that I wrote a while ago. The big difference is that this module is written in PHP 8 and has some nice additional features. The old module could only publish and unpublish pages depending on date and time settings, but the new version goes much further. So you can decide what should happen after the publication end date has been reached. You have the following options: Unpublish the page - this is what the old version did Move the page to trash - new Delete the page permanently- new Move the page to a new position in the page tree - new The last option will be interesting if you want to move the page fe to an archive after a certain date. You can select the new parent page and after the publication end date has been reached, the page will be moved under the new parent page. You will find a more detailed instruction and download possibility at https://github.com/juergenweb/JkPublishPages This module is Alpha stage and should be tested carefully before using it on live sites. I have planned to add this module to the PW module download section, so everyone is invited to test it out and to report issues directly at GitHub. Thanx
    1 point
  3. Ok, found the issue. I am using composer and I has an installation of the processwire/processwire package of different version and the composer's autoloader loads the files from the vendor folder first. Fixed by either removing or upgrading the composer package.
    1 point
  4. It seems that the .htaccess file is buggy. I played around with an old version of Processwire what was still working. When the .htaccess was replaced it worked again. Maybe lateron I will look into the problem in the .htaccess Ok. This is awkward. In VSCode my .htaccess file was reformatted this was causing the issue
    1 point
  5. This module is from Ryan, you don't have to worry about it.
    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. Hi, by “static pages” do you mean statically served HTML files generated outside of ProcessWire? Or do you want to add a blog to an existing ProcessWire site? I see you’ve been here for several months, so I’m assuming you’re somwhat familiar with PW. It should be a breeze to get a blog going. At its barest, it’s just a template with a title and a body field. For categories, there are different approaches you can go with, depending on how structured you want your data to be. Some blogs just have free-form textual tags, some have fixed categories that work like subdirectories, or anything in-between. Is there anything in particular you’re thinking about?
    1 point
  8. The problem here is that I've set up various Hanna code tags and, since I'm going to create many new ones increasing their number, the list of code tags in the PW admin backend (Admin > Setup > Hanna Code) will be a mess e.g. it'll be hard to find one Hanna code among the many created ones. A solution to this problem could be to name Hanna code tags with a criterion, but what is a good practice for naming them? How do you keep organized/ordered your Hanna code tags in the PW admin backend?
    1 point
  9. You could use a hook... $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); if($page->template == 'your_parent_template') { $selector .= ", sort=date, sort=title"; $event->arguments(0, $selector); } }); ...or this module: https://modules.processwire.com/modules/process-page-list-multiple-sorting/
    1 point
×
×
  • Create New...