Jump to content

ryan

Administrators
  • Content Count

    12,819
  • Joined

  • Last visited

  • Days Won

    721

Everything posted by ryan

  1. @Klenkes @eelkenet @Jens Martsch - dotnetic Thanks, I was able to duplicate and fix the issues mentioned above. Please let me know if you observe any other issues.
  2. @Jens Martsch - dotnetic Heh, no problem, that happens here regularly too. :) Let's get back to your first video—I'm trying to figure out how to duplicate this one. I think you could be on to something here because many Fieldtype methods require a Page object, and there is no Page object associated with each image. As a result, we use a fake Page without an ID, and I'm guessing this is the source of the error you are seeing, but I can't figure out how to duplicate the scenario here. Here's what I've done to attempt to duplicate: I've started with a new instance of the "Regular" site profile, added a field-images template, and added fields to it. Logged in as superuser, I edited the /about/ page, uploaded an image to the image fields, and populated all my custom fields with text, and saved. I created a new role named "editor" and checked the box so that it has page-edit permission to "home" (which inherits through the tree). The user doesn't have any other permissions. I created a new user with this role, logged in with it, and edited the /about/ page and clicked to open the images field. I can see all the field text, and modify and save it as well, and changes are retained. So I'm not sure what to try next in terms of duplicating the issue, so I'll ask a few questions; Do you have any field-level access control involved here on your images field, or on any of the fields defined on your field-images template? Did you enable access control on your field-images template? (it should be disabled) Do you have any modules installed that add access control hooks or modify the way access control works? Do you have any optional core permissions installed? (like page-edit-created, page-publish, page-edit-images)? Any other factors you can think of? Thanks!
  3. @Jens Martsch - dotnetic Thanks for the videos. Let's focus on your 2nd example first, because I see things in first one that I don't recognize, and it looks like there is access control at the field level too, so lots of factors—let's come back to that one. In your 2nd example (blank installation) you haven't yet uploaded an image into the field, so it doesn't look to me like it should be showing any fields yet. But you are circling something with your mouse, so I'm not sure I understand. But you shouldn't see any of your custom fields if you haven't yet uploaded any files/images yet, so can you try that example again or let me know if I misunderstood? (no need to record it to a video, just wanted to make sure I wasn't missing something).
  4. ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40— https://processwire.com/blog/posts/pw-3.0.142/
  5. Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.
  6. Actually I'm still working on minor details, but I'll have it posted by 5pm EST.
  7. This week’s dev branch version brings you improvements to ProcessWire’s $input->cookie API variable, plus it adds the ability to modify system URLs and paths at runtime. This post also includes some examples to demonstrate just how useful this can be— https://processwire.com/blog/posts/pw-3.0.141/
  8. No blog post this week because I don’t have anything new or interesting to write about just yet (unless you like to hear about repairing fridges and clothes dryers). But I’ve been focused primarily on completing the FormBuilder updates that I mentioned in last week’s blog post, and it’s looking very good, though I’ve still got a little further to go with it. When it comes to multi-page forms, I’m trying to cover all of the exceptional cases where sessions expire, cookies clear, etc., and want to make sure a form-in-progress continues to work through all these situations. Multi-page forms can be potentially long and people can invest lots of time in them (relative to regular forms), so trying to make it all as resilient as possible. This takes lots of time developing and testing, so that’s what I’ve been doing. I’ll be doing some of that next week too, though also have been planning to dig back into the core issues repo and start working through some of those in preparation for a new master version this Fall. Hope you all have a great weekend!
  9. @dragan Thanks for testing it out. I don't think it's the query string, as the Toggle field doesn't work with query strings or GET var input. I'm guessing more likely is that AoS is applying some kind of customizations or JS events to radio inputs, and these are conflicting with the events that Toggle uses to make radio inputs look like toggle buttons. Why it's only affecting the "Yes" state though is strange, as I'd expect it to affect all the state, but maybe it has something to do with Yes being the first in the list of inputs, or something along those lines.
  10. Glad you found it. Any particular feature in that module that you found is interfering with the toggle field? Maybe it's something I can test with and work around.
  11. @wbmnfktr I haven't worked out all the details of this part yet. But fields in an integrated form are still present when it comes to what actions can do with them. They are just renamed to have the field name that represents the "form" field as a prefix for each field in the integrated form. So anything that maps the fields in a form to something else (like a page or spreadsheet) will likely continue to work the same way that it currently does, but would have the integrated forms "opened" (for lack of a better term) so that their fields can be mapped like the others.
  12. @teppo I'm not sure why that is. Maybe it needs me to add a version tag to it to jog things loose? Anything else you can think of I should test or try from here?
  13. @Robin S Not yet interactively, though it is possible with hooks. Though I do plan to make it part of the "Form" field settings once the field gets more mature. Yes. Existing dependencies in forms you integrate will continue to work, and you can also make fields in the main form be dependent upon fields within an integrated form. The field name for fields in an integrated form is "formName_fieldName" rather than just "fieldName". That's how you can integrate multiple copies of the same form, and still end up with unique field names. So if using dependencies, then you just refer to the "formName_fieldName" in your dependency. For existing dependencies in an integrated form, FormBuilder takes care of converting those for you, so that the dependency works regardless of where else the form is used. Each page is validated independently. It creates a partial entry on the server side (in the DB) and saves it on submit of every pagination. If there are errors on the pagination you submit, it will stay on that pagination until you fix them. Yes. Partial entries also have their own URL (unique query string) that can be bookmarked or returned to if someone doesn't want to complete it all in one setting or their session expires, etc. Yes, but probably not in the first version. Though this is part of the reason why it's setup so that partial entries have their own URL. The page number can be specified in the query string. Any pagination has access to the entire entry server side (should you want to examine anything with hooks), but the front-end/client side only knows about the current pagination. So dependencies across paginations won't work at present. If there's interest in the feature, the plan was to support it by rendering the non-present Inputfields referred to on any pagination's showIf/requiredIf values within the current pagination, but behind a hidden element. In that manner, they are technically present for the pagination's processing and front-end JS, even if not visibly present.
  14. @dragan @matjazp I setup a new toggle field exactly as shown in the screenshot, but can't duplicate the issue. Maybe it's something browser specific or maybe it's getting interference from some other module? Do you see any JS errors? Any other factors you can think of?
  15. This week we’ll take a look at a new version of FormBuilder that's on the way (with a screencast), as well as the latest version of the core: ProcessWire 3.0.140— https://processwire.com/blog/posts/pw-3.0.140-and-formbuilder-v40/
  16. This latest version of ProcessWire on the dev branch adds a new Inputfield module called “Toggle” that is an alternative to the existing Checkbox Inputfield. It also adds a nicer way to make column width adjustments to your fields when editing a template. This post covers all the details with screenshots and a short video: https://processwire.com/blog/posts/pw-3.0.139/
  17. @bernhard Making it hookable should be fine. But I'd like to better understand what you mean about it not working in the admin, and the url and filename methods never getting called? Are you using the core files/images field? Those methods/properties are the ones used for anything asking for the filename or url of a file, whether on the front-end or in the admin. For me at least, it works the same in the admin/page editor as it does on the front-end, just tested again to confirm—editing a page downloads the images, and they appear in the images field in the page editor. So I'm not sure I understand what you mean? Also, hooking setFilename() would make it less on-demand, as it would download any images in the field rather than only those that were specifically requested. Can you think of anything different about your environment that might account for it not working?
  18. Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!
  19. @iipa Pasting stuff from Word should be no problem ... I think most of our clients likely do this. So you definitely shouldn't get an internal server error from PW at least. Though you might try setting $config->debug=true; in your /site/config.php file (temporarily) and trying again, just in case — that will make it produce a verbose error message. But it's more likely that it is coming from mod_security or some other Apache or PHP module on the server that is monitoring input and halting the request when it comes across something it doesn't like. I don't blame it, as MS word can produce some pretty sketchy looking markup. But between CKEditor and htmlpurifier, PW should be able to clean it up just fine once the server lets it through. But if it's an Apache/PHP module doing this (which seems likely) then nothing you adjust in PW can fix it since the module examines the request before PW even boots, so you'd instead have to disable or configure the Apache module (mod_security, suhosin, or whatever it might be).
  20. ProcessWire added WebP image support this year and many have been adopting it enthusiastically in existing projects. In this post we’ll look at a process used for migrating an existing website to use WebP images. We’ll cover everything from preliminary considerations to implementation and testing, with lots of tips and tricks along the way— https://processwire.com/blog/posts/webp-images-on-an-existing-site/
  21. Just a quick update this week. I’ve got a good post in the works that I thought I’d have ready for today, but didn’t have quite enough time to finish it, so going to save it for next week. Though there's a module that's part of the post, and since it is ready, I've posted it below. We’ll look at ProcessWire 3.0.138 next week as well. I do have a couple of non-core updates to mention this week though. First is that I’ve released a new Textformatter module that converts any image references in your CKEditor/textarea fields to WEBP images on-the-fly as pages are rendered. If you are implementing WEBP on your site, you’ll find that the images placed in rich text fields are the most tricky ones to serve as WEBP, so this module takes care of that task for you. It's in the modules directory or at GitHub: https://github.com/ryancramerdesign/TextformatterWebpImages I’ve also released new development versions of the ListerPro and Export CSV modules, both of which are available to subscribers in the ListerPro support board. Some of the new features are actually built into the core, but currently only utilized by ListerPro. There’s quite a bit of new stuff, so there’s also an ~18 minute screencast that walks you through them, which can also be found in the ListerPro board.
  22. I'm running into this issue on my localhost (MAMP) where it reports PHP’s standard "Fatal Error: Maximum execution time of 120 seconds exceeded" before even 1 second occurs. It does this regularly, but not all the time. But if I'm clicking around pages, I'll see often (maybe 1 out of 7 requests), and it halts the request. The file reference is always somewhere in either ImageSizerEngineIMagick or ImageSizerEngine, though a common place is on the line that instantiates the IMagick instance in the processResize() method: // start image magick $this->im = new \IMagick(); I looked into the ImageSizerEngine::setTimeLimit() method in detail, but there's no problem I can spot in there. I have no idea what the issue could be, but just replying here since @Mikie also ran into it, so it seems to be reproducible. Though it's a weird anomaly that we should never see unless 120 seconds actually passed (but they didn't, not even close). I haven't observed it occurring on any live servers yet, just my localhost environment on PHP 7.2.10. I'm guessing the issue might be PHP version specific or IMagick version specific since it appears to be PHP outputting an error with false information. Posting here in case anyone else has insight on what it might be.
  23. Core version 3.0.137 on the dev branch adds the ability to hook multiple methods at once, in a single call. This post details how it works and provides a useful example of how you might put it to use in your development environment. This version also refactors and improves upon several core classes— https://processwire.com/blog/posts/pw-3.0.137/
  24. ProcessWire 3.0.136 upgrades the version of CKEditor from 4.10.1 to 4.12.1. While that might look like a minor version bump, it’s actually 5 versions ahead and includes quite a lot of new features, changes and fixes. See the CKEditor release notes for more details on all that's been added and changed in the last 5 versions. It was a year or two ago where it seemed like CKEditor was going to be phasing out CKE 4 in favor of CKE 5. But interestingly it now seems like there is a new focus in CKE 4 from the CKEditor folks, so I’m going to have to start watching the version updates more often. Of course, I remain interested in CKE 5 too, but it’s nice to see CKE 4 (my favorite editor for a long time) going so strong and getting new features and attention, which is also a nice benefit for all of us PW users. I’m looking forward to working with some of the new stuff they’ve added in recent versions as well. For instance, the autocomplete feature sounds like it has nice potential for inserting Hanna codes or links to other PW pages, among other things. Also new in 3.0.136 is a new Debug::backtrace() static method in the core. I often use PHP’s debug_backtrace() method when debugging (and it appears in PW’s fatal exceptions), but the reality is it gives me a lot of stuff I just don’t want… all the hook method calls and such that aren’t usually relevant to what I’m trying to find. So the new built in Debug::backtrace() method returns a much simpler array than PHP does, and it also excludes all of the [likely] irrelevant internal hook method calls, and is just generally more focused on what you are likely to need from a backtrace in ProcessWire. It’s very convenient to plug into a ProcessWire $wire->message(Debug::backtrace()), or a Tracy Debugger bd(Debug::backtrace()); or even an echo '<pre>' . print_r(Debug::backtrace(), true); call. Though please consider this new method a work in progress, as it’s just a start at the moment and is likely to get additional updates. At some point, PW’s fatal exceptions will likely use the output from this method as well. Since this is kind of a short post, I’m just posting in the forums rather than creating a new blog post. More core updates on the way next week. Hope you all have a great weekend!
  25. This week I was catching up with client work after traveling last week, but some of that work overlapped with a focus on WireMail modules. As a result, this week I’ve released two new WireMail modules, and also have information in this blog post on how you can configure two existing WireMail modules (WireMailSmtp and WireMailPHPMailer) to use Gmail as the SMTP sender— https://processwire.com/blog/posts/wiremail-modules-and-gmail/
×
×
  • Create New...