Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ryan

  1. @Ivan Gretsky Hooks have already been added for this, and I think they were present in the dev version I posted in the ProFields board a few months back? I don't remember for sure, but I'm trying to make everything hookable so that people can modify the output as needed, and will keep looking for additional opportunities for that as I build in more related features. @teppo Yes there's a renderAddMatrixItemLink() hookable method for this, and it renders a link for one matrix item type, and gets called for each of them. So you could change the output to be anything you want. This is already present, but with the changes being made, chances are another hookable method will be added related to this. @Pete If I understand correctly, this is already there. See the "Matrix types to allow for adding new items" on the "Input" tab when editing your matrix field. This can be configured in template context which enables you to specify some types for one template and other types for another, etc. @mlfct Thanks, I was able to reproduce that here too and have pushed a fix on the dev branch.
  2. It took a little more time this week to wrap up what I was finishing last week (and the week[s] before). But I think it's now at a good spot to move on to something else, and so I started with some Repeater and RepeaterMatrix updates. In Repeater, a new feature was added that's been requested for awhile: the ability to add items anywhere you choose. Previously you could do it only by adding items to the bottom, and then drag them in place. Now you can click insert before/after [icons] in each repeater item header and it will add the new item in place. It is also depth-aware. This is something that I think will also be useful especially for people using repeaters for page builder type contexts. (Note: the feature does not [yet] work if you have all Ajax features turned OFF in your repeater settings). There's a GIF screencast below that shows you how it works. You can click the "insert before" or "insert after" actions and it inserts a new item in place. Alternatively, if you hover either action for a second, it'll show you where it's going to insert an item and you can click either the the item, or the action, to complete the insertion. There's still likely some optimizations and improvements to make in the JS here but so far it seems to be working well. (I made this as a GIF but for some reason IP.Board won't accept it, so here's a YouTube embed instead): Everything in Repeater also gets inherited by RepeaterMatrix, so you'll find this feature there too. But it's not fully functional there just yet. That's because RepeaterMatrix items also have a "type", so I'm working on a new version of RepeaterMatrix that lets you select a type once you've chosen where to insert the item. Another related feature in progress in RepeaterMatrix at the same time is a dropdown/select option for choosing what matrix type you want to add for items. This is an alternative to the current list of links that appears at the bottom. The dropdown also gives you the option of having groups of related types. More on that soon, potentially next week. Thanks for reading and have a great weekend.
  3. This week I kept working on what's been in progress the last couple of weeks. That wasn't really the plan, as I was hoping to move on to other parts of the core. But I found it a took a lot of time to adjust everything to the new code and classes, and to refactor and remove other chunks of code that could either be simplified or removed. So these last few weeks of updates took a lot more time than I expected, and it's one of those things where once I got into it I felt I had to keep working until it was done as well as it could be. That meant getting pretty deep into some core logic. So in hindsight I'm slightly regretting refactoring so much code without major short-term benefits that can make more interesting reading here. And there are perhaps some short-term drawbacks in potentially introducing new bugs, as goes with any new code. But that's how it is sometimes. The good news is that it's a definite improvement in quality and I have no doubt there will be long term benefits especially in terms of improved performance and maintainability. But in any case, I'm glad to be wrapping up these particular updates so that I can move on to other parts of the core and Pro modules, and hopefully I'll have more interesting stuff to write about next time. One small addition you might find useful in these updates is that you can now identify the closest matching page when a 404 occurs. Maybe you want to provide a hint to users that land on a 404 as to what page they might have been looking for. Now you can do this in your 404 page template file: $p = $pages->request()->getClosestPage(); if($p->id > 1) { echo "<p>Were you looking for <a href='$p->url'>$p->title</a>?</p>"; } Like last week I'm not bumping the dev branch core version just yet because I don't want to trigger any upgrade alerts that might prompt people to upgrade immediately. I'd rather focus more on testing and leave these updates to those that are interested in that testing, helping to track down any issues. Thanks in advance for your help with testing these updates. Likewise, thanks for reading, I hope you have a great weekend!
  4. @kongondo It shouldn't have any impact on those files and the same rules apply for when the $page API variable is available. The difference now is that you could potentially call $pages->request()->getPage(); on your own to find out what page it's going to be before the rest of PW knows. I think this probably isn't a common need, but the best example I've been able to think of is that SessionAllow module, which would like to know what the current $page is going to be before it decides whether or not to start a user session. That getPage() method is also hookable, so you could also dictate what the $page API var is going to be if you wanted to. Or you could call $pages->request->setPage($page); before PW calls getPage(). @Ivan Gretsky We couldn't make the getDefault() hookable because usually when code calls that, it's because it literally needs the default language and not one that's been substituted for it. So I think we'd have to focus further in on what you are wanting to do, or what front-end logic you are wanting to change, to see if that could be made hookable. That pageNotAvailableInLanguage() method was added to enable hooking into the logic of what the method describes, but perhaps other types of logic can be made hookable too.
  5. All the updates I mentioned last week are committed on the dev branch today, and it's quite a lot of new code and revised code. There's enough here to justify a couple of version bumps, but I'm leaving it at 3.0.185 temporarily because the ProcessWireUpgrade module will see the version change and some people might upgrade automatically. Because there's so much that's been rewritten, refactored, added and changed here, I'd like it to marinate for a week on the dev branch before it triggers any upgrade notifications. Our dev branch tends to be very stable, and this is one week where there's enough new code that I don't want to call it as-stable-as-usual just yet (though it might very well be). In addition, it's also not totally finished as there's still some redundant code to be removed and stuff that needs to be moved around a bit, though everything should be fully functional as-is. I am running it here on the processwire.com site without any issues, so chances are that all is good, but I always like to be cautious. Below is a summary of what's new and changed. It's a bit technical, and there's nothing here that's all that important to know about, but whether you read on or not, just know that the core is getting even better and faster with updates like these. The core PagePaths module has been refactored and has multi-language support. Previously it only worked on single-language sites. Now multi-language sites can take advantage of potentially significant performance improvements offered by this module. This is one module that is not installed by default, but it's definitely worth installing: Modules > Core > PagePaths. The core LanguageSupportPageNames module has been refactored. Assuming I did it well, you shouldn't notice any difference other than that it's faster. For instance, one of the changes is that it drops its old indexes on the pages table and re-creates them in a different way. I discovered some situations where finding pages by multi-language path was resulting in full pages table scans. Using MySQL “explain” statements I found I could prevent that by reversing the order of the columns in the language-specific indexes, preventing the full table scan and making it many times faster. This could make a big difference on large multi-language sites, but is less likely to be noticed on smaller sites. The LanguageSupportPageNames module also gained a new configuration setting that lets you specify what should happen when a page is accessed at a language it's not available in: throw a 404 or redirect to the default language. The core PagePathHistory module has been refactored. It has a powerful new getPathInfo() method, though it's primarily of interest for internal core use. A new PagesRequest class has been added to the core and it can be accessed from $pages->request(). It primarily focuses on one hookable method: $pages->request()->getPage(). The method accepts no arguments but it analyzes the current request, identifies the page to render, and returns it. Previously this logic was in the ProcessPageView module. The benefit of this method is that you can now determine the page to render much earlier, like during the boot process. Previously the current page wasn't identified until after PW booted and the ProcessPageView module loaded. This will enable [for example] a module such as SessionAllow to decide whether or not to allow sessions based on what page was requested. In addition, this method is hookable, so you could have a module that adds its own logic to identify or change the page that should be rendered. A new PagesPathFinder class has been added to the core and can be accessed from $pages->pathFinder(). Like the PagesRequest class, this new class primarily focuses on one method: $pages->pathFinder()->get($path). The given $path can contain any page path, optionally containing language prefix, URL segments, pagination numbers, or even a previously named version of the path. It will find and validate that path and return an array of information about it. PagesPathFinder does its job very quickly. In fact, it's about 10 times faster (in testing/timing locally) than PW could previously identify this information using existing methods. PagesPathFinder will also take advantage of the PagePaths and/or PagePathHistory modules when appropriate, if they are installed. Below is an example of what the return value would be for path /es/hello/bar/baz/page3 where /es/ is the language prefix, /hello/ is the actual page, /bar/baz/ are the URL segments and /page3 is the pagination number segment. It analyzes everything out and returns a 200 "ok" response if the path is good, or in this case, it's returning a redirect because it detected a Spanish URL with English page name and pagination prefix, and it's suggesting a redirect: $info = $pages->pathFinder()->get('/es/hello/bar/baz/page3'); [ 'request' => '/es/hello/bar/baz/page3', // path that was requested 'response' => 301, // one of 200 (ok), 301 (permRedirect), 302 (tempRedirect), 404 (pageNotFound), 414 (pathTooLong) 'type' => 'permRedirect', // ok, permRedirect, tempRedirect, pagePathError, pageNotFound or pathTooLong 'errors' => [], // array of error messages indexed by error name 'redirect' => '/es/hola/bar/baz/pagina3', // suggested path to redirect to, blank otherwise 'page' => [ // info about page that was matched 'id' => 1237, 'parent_id' => 1232, 'templates_id' => 12, 'status' => 1, 'name' => 'hello' ], 'language' => [ 'name' => 'spanish', // name of language detected 'segment' => 'es', // segment prefix in path (if any) 'status' => 1 // language status where 1 is on, 0 is off ], 'parts' => [ // all the parts of the path identified [ 'type' => 'language', 'value' => 'es', 'language' => 'spanish' ], [ 'type' => 'pageName', 'value' => 'hello', 'language' => 'default' ], [ 'type' => 'urlSegment', 'value' => 'bar', 'language' => '' ], [ 'type' => 'urlSegment', 'value' => 'baz', 'language' => '' ], [ 'type' => 'pageNum', 'value' => 'page3', 'language' => 'default' ] ], 'urlSegments' => [ // URL segments identified in order 'bar', 'baz' ], 'urlSegmentStr' => 'bar/baz', // URL segment string 'pageNum' => 3, // requested pagination number 'pageNumPrefix' => 'page', // prefix used in pagination number 'scheme' => 'https', // blank if no scheme required, https or http if one of those is required 'method' => 'pagesRow', // method(s) that were used to find the page ] While you might never need to use this method yourself, ProcessWire now uses it on every request. And now that this logic is isolated from ProcessPageView and has a dedicated $pages API, it's much more open and we can, for example, more easily apply tests to this logic. I've covered a few updates here but there's more if you feel like digging in the commit log https://github.com/processwire/processwire/commits/dev. Thanks for reading and have a great weekend!
  6. There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.
  7. This week I've been focusing on the dev branch and some low level code optimization, especially as it relates to the PW boot process, translating URLs to pages and identifying the page, language, URL segments, page numbers, etc. from the request URL. I'm breaking down much of the logic (currently in the ProcessPageView module) into more focused parts that can become part of PW's $pages API, increasing reusability of related code. (Don't worry, this won't affect any existing hooks). At the same time, I'm looking for opportunities for optimization and performance improvement, and have already found a few. For instance, the LanguageSupportPageNames module introduces overhead into some page finding operations and there's good improvement potential there, among others. I'm pretty much still in the middle of it all though, so am going to hold off on committing any of this to the dev branch until it's further along. But since we've got a quiet commit log this week, I just wanted to keep you up-to-date. Hopefully some of these fairly significant updates will be stable enough to commit to the dev branch next week. By the way, these updates will also enable the SessionAllow module (from last week) to be configurable by page, as PW will now identify the requested page before starting the session. More soon. Have a great weekend!
  8. ProcessWire 3.0.185 is the latest version on the dev branch this week. Relative to the current master (3.0.184) this is 9 commits ahead and contains various minor fixes, improvements and additions. Since our current master version is quite stable and no significant issues have surfaced since release, we'll likely be focusing on the dev branch for several versions before merging back to the master/main branch. For details on what's new in 3.0.185 dev see the commit log. ProcessWire Weekly #383 also includes some details on a few new selector features added last week that you'll find in this version, read about it here. Today I've posted a new module in the directory called Session Allow. This module enables you to configure whether to allow sessions for each request based on simple configured rules. Currently it requires ProcessWire 3.0.184 or newer. The reason I built this module is that I find the current $config->sessionAllow setting (where you define a custom function) can be a little complicated to work with, especially since it gets called before most of ProcessWire’s API can even be used. This module aims to make control of sessions a lot simpler than that. The benefit of being able to control when a session is allowed is that it lets you better focus your resources for sessions to just the requests where they will be needed, helping to reduce server overhead and improve performance. Currently it supports allowing (or disallowing) sessions based on page path matching rules and hostname matching rules. I also plan to add support for sessions allowed/disallowed per page template, which I think would be really useful. But it'll take some changes to the PW core to support that, as ProcessWire starts the session before determining what page has been requested (and thus what template will be used). So I'm going to make the necessary core updates and then save that feature for version 2 of this module. I'm releasing the module as "alpha" right now because I rushed a bit to get it out for today and feel it needs more testing before I can call it stable. So if you are interested in using it, make sure to test everything out in a development environment first. And if you do get a chance to test it, please let me know how it works for you. Thanks for reading and have a great weekend!
  9. @horst Like with matching a "parent=" or "has_parent=", it just sends the path to another $pages->get('...'); call to lookup the ID, so it should work with any path that $pages->get() would accept.
  10. This week there are a few minor updates on the dev branch, though not enough yet to bump the version. The most notable are a few improvements to the database selectors you can use with $pages->find() and similar API calls. While working through issue reports a few weeks ago, there were a couple issue reports that indicated one selector or another not working. What I found was that it was working as designed/built, but they were just selector features that had never been supported. But they also seemed like good/useful shorthand syntax to support, so I was enthusiastic to add support for them. I just wanted to wait till we were back on the dev branch, as we are now. Here's what's been added: Support for OR values on "status=" selectors. Now you can match one status or another with PageFinder selectors by specifying a selector like "status=hidden|unpublished", and this will find all pages that either have hidden or unpublished status. The hidden and unpublished are just likely the most common examples, but you can use any other status name, or as many statuses as necessary in your OR condition. Previously it was possible to match pages having one status or another by other means, but it was far from straightforward. Now it's nice and simple. Support for OR values on "sort=" selectors. This one isn't technically an OR condition since we are giving a command to the selector engine about how it should sort, rather than trying to match something. You can tell it how to sort with the syntax "sort=date|title" as an example. That would be shorthand for "sort=date, sort=title", which is saying "first sort by date, then by title". Support for combined start and limit selectors. Previously you have had to specify "start=x, limit=y" separately, if you needed it. Now you can optionally specify both as part of the "limit", for example "limit=5|10" which is shorthand for "start=5, limit=10", and actually kind of similar to what it translates to in MySQL, which is "LIMIT 5,10". I suspect that not many people ever use "start=" in their selectors unless using "start=0" to prevent a set from paginating. So if you wanted a set of 10 pages that don't follow the current pagination, you could specify "limit=0|10" in your selector, or the more verbose "start=0, limit=10" will work in any PW version. Support for matching children paths. This is a small one, but previously you couldn't do "children=/path/to/page" to match a page having the given child path. Though you could do "children=123" where 123 is the ID of the child page. It has been updated so that it can now support paths in addition to IDs, just as "parent" does. I'm not sure why we didn't have support for this one before, it likely just hadn't come up yet. You can use OR values here too if you'd like. As before, you can also use subfields on "children" as well. Worth mentioning is that these are additions for our PageFinder engine which queries the database. We also have the lesser used in-memory selectors which don't yet support all of these, but I've put it on my to-do list. In-memory page finding selectors come into play if you are post-filtering pages that you have already loaded from the database into a PageArray. We like these to maintain some consistency with the database selectors when possible, so I'll likely have that working here soon. From this end, I'm also putting ~2 hours of work into the new Pages Snapshots module every day, with a lot of progress but also still a lot of ground to cover. Separately, I'm working on pulling more than 4 million articles out of an older proprietary legacy CMS for a newspaper organization and converting them to a standard XML format for import elsewhere. A lot of data conversion has to take place in terms of cleaning up markup for each article. ProcessWire is the tool that all of this is being done in, and I'm using a lot of $sanitizer methods as well as keeping HTML Purifier busy! Thanks for reading and have a great weekend!
  11. @MarkE Was this bodyFoot thing querying the database, or doing something memory? When querying the database with something that uses an index, it can be affected by what characters MySQL indexes as part of a word. Though I think MySQL would much more commonly index "myText" and not "<p>myText". It may come down to more specifically what the exact text that you are using in that bodyFoot query, like perhaps it's matching a stopword? Or if this is a selector that isn't querying the database, it could be tested like this: $value = WireData([ 'text' => '<p>myText, some more text, ... </p>' ]); $tests = [ 'text*=myText', 'text%=myText' ]; foreach($tests as $test) { $s = new Selectors($test); echo "<li>$test: " . ($s->matches($value) ? 'Yes' : 'No'); } I get "Yes" for both fo the tests, indicating it matches. Though I recognize this is probably not the real text you are matching.
  12. @MarkE That I think may be defeating the purpose of making it load on-demand. What I intended to suggest is to add that adminSite() function, and then replace any of your calls with setting('admin_site') with adminSite(). For example, rather than calling setting('admin_site')->pages->get('...'); you'd call adminSite()->pages->get('...'); and it should do the same thing. The main difference is that your admin site doesn't get booted until the first time the adminSite() function is called. That's desirable because it prevents you from booting it when you aren't going to access it, saving overhead. A function can only be defined once, so it doesn't matter where you call adminSite(); from whether site-admin or site-web. Great! Glad that it seems to be working now. As for why the *= wasn't working, I think we'd need to look at what is in $host in order to tell. It would also be good to know the full context of that bodyFoot*=$host, for instance is that selector being sent to a $pages API call, or to something else? The biggest difference between *= and %= is that *= matches from the beginning of a word boundary whereas %= matches anywhere in the string. So if you've got an instance where %= is matching and *= isn't, then most likely it's because of that difference. If its querying the database, then *= is also subject to stopwords and minimum indexable word length (typically 4) whereas %= is not. @AndZyk Interesting, I'll have to try that out. Are you using the latest German language pack released by @dotnetic or a different/earlier one? I think the capitalization issue might not be specifically with InputfieldTextTags but with its usage in ProcessField/ProcessTemplate. I don't think there's a reason to avoid using it elsewhere. @kongondo The InputfieldPage had to be added because often InputfieldTextTags is used in combination with InputfieldPage. The jQuery selector ".InputfieldTextTags, .InputfieldPage" seems to be valid. Does the error trigger on that line in particular, or does it occur sometime later? Do you find there is any difference if you set $config->debug = 'dev'; ? That will make it use a newer jQueryCore version. That was throwing up the JavaScript error I posted above. My remedy was to let ProcessWire Inputfields trigger the reload, like this: Glad that seems to have fixed it. If this works, and triggering 'reload' manually didn't work, it means that $myInputfieldTextTagsSelectItem is not an .Inputfield element. The 'reload' event is is specific to .Inputfield elements, so the Inputfields.reload() method will attempt to locate the and trigger the .Inputfield element if given something other than an .Inputfield. I think that must be why it is working when the manually triggered one wasn't?
  13. @wbmnfktr I don't see anything wrong there, that all looks like exactly what it's supposed to do. It may be a bit verbose but I think that's best when debug mode is enabled, especially on new installations. Rest assured, all looks well with your installation. It's kind of like how when you buy a new computer or phone, it installs whatever updates are needed to ensure that everything is up-to-date. @shadowkyogre This is not new to 3.0.184, but check to see if your title field is globally required on all templates. If so, you may want to disable that setting. It is in the field editor on the "Advanced" tab, when editing your title field. Or if you just want to disable the setting for the template that you are using, enable $config->advanced=true; in your /site/config.php file, edit the template in Setup > Templates, click the "System" tab and check the box to "Disregard global fields", for that template. Then remove the advanced setting from your config.php file, unless you want it for something else. @MarkE I'm not aware of a difference that would affect that, but wanted to suggest booting your other site on-demand rather than on every page render. So I would replace your setting() call with the following: if(!function_exists('adminSite')) { function adminSite() { static $instance = null; if($instance === null) $instance = new ProcessWire($config->paths->root . 'site/'); return $instance; } } Then anywhere you need your instance, do your calls like adminSite()->pages->get('...'); Next, make sure that your instances are both running the exact same ProcessWire version. The other thing that's a little unconventional here is that the site you are booting is using the /site/ dir, which is ProcessWire's default. Usually if booting another instance, it would be in a different location or be using a /site-something/ dir rather than the default. I'm not sure if that's a potential issue or not, but wanted to mention it just in case. You might want to rename your /site/ to /site-admin/ so that there is no /site/ directory which would typically be the primary instance. I can assure you that PW isn't editing your file. But I agree that is really weird. Whatever is doing that might be the source of the issue. This sounds like the sort of issue I run into when I edit a file on the wrong node of a load balancer, and a moment later it gets replaced by the primary node. Make sure that you are using <?php namespace ProcessWire; at the top of your templates and any other PHP files, just to rule out anything file compiler related. Also check what /site/modules/ you have installed just in case.
  14. Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. 😜 This can be especially useful if your ProcessWire database uses the utf8 character set rather than utf8mb4, as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference
  15. @AndZyk I haven't been able to duplicate that issue, but to me it sounds like maybe browser cache. I am also using MAMP locally (though not MAMP PRO). You might try incognito mode to see if that makes any difference. If that's not it, then it might be worth checking if any other modules are installed that might be conflicting with InputfieldTextTags, as the error does seem to be originating there. Please let me know if you find anything more. Regarding mixed capitalization in tags, there's an open issue report on GitHub for this. I spent half a day trying to fix it a month or so ago, but couldn't figure it out and gave up on it temporarily to try again later when back to the dev branch. Until we have a solution for that it's likely preferable to avoid mixed case tags for fields or templates.
  16. TextformatterEmoji converts named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. For instance :smile: converts to: 😄 This can be especially useful if your ProcessWire uses the utf8 character set rather than utf8mb4 as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Note that how the emoji appears (and sometimes whether it appears) can vary from platform to platform, and from browser to browser. Here is an alphabetical list of supported emojis and the shortcodes you can use to show them in your text. If you want to add any emojis that are not already present you can do so in the emojis.json file.
  17. This week we have a new master/main version released after a full year in the making. With nearly 40 pull requests, hundreds of new additions and more than 100 issue reports resolved, this new version has a ton of great new stuff and we’ll cover most of the new stuff here— https://processwire.com/blog/posts/pw-3.0.184-master/
  18. @hollyvalero Looks like I broke it on the dev branch trying to resolve another issue report on Friday. Sorry about that, I have just pushed a fix. Thanks.
  19. This week the dev branch contains about a dozen issue fixes relative to this time last week. (commit log) While these are all relatively minor things, some have been around awhile and it's always nice to get them figured out. Plus it's often a good opportunity to iterate and improve upon related things in the process. While I think we're very close to being ready to merge to the master branch, I'm going to give it a few more days just in case. I want to make sure no new issues arise (no matter how small) as a result of all the commits we've been doing over the last few weeks with GitHub issue resolutions. Most likely there won't be many more commits on the dev branch before the merge, and perhaps by this time next week, we'll have version 3.0.184 as our next master version. Following that, I'll write up a post that documents everything new relative to the previous master version 3.0.165, as there has been quite a lot! But if you want to upgrade now, I do think there's very little risk in upgrading existing master/main installs to the current dev branch, as it is quite stable at this point, in my experience. Thank you for all of your help in testing and/or reporting issues. Have a great weekend!
  20. Work continues on the next master/main version here as we close out older issue reports and finish minor tweaks and adjustments. Eight issues were resolved this week. That might not sound like much, but with the most pressing issues already resolved, more of the GitHub time now goes towards discussion, support and more administrative related stuff, than to actual work in code. Issues remaining and being worked on are those that affect very few and might be more time consuming or difficult to reproduce, or are more subjective. We're very close to our next master version and unless anything new that's particularly pressing arises this coming week, I think we may be there next week. If you have a chance to help us test the current dev branch, please do. Thanks for your help and have a great weekend!
  21. Relative to ProcessWire 3.0.182, today's version (3.0.183) contains about 30 commits and resolves 23 issues. It also contains various small tweaks and improvements throughout. For example, when editing the title of a page, it updates the headline as you type in the page editor (in Uikit and Reno admin themes). I think we've got another 1-2 weeks of these kinds of updates (resolving issues and minor improvements) before we release the next master version, and am currently thinking that version will carry version number 3.0.184. I'm also continuing work here on the page snapshots module I wrote about earlier, but am going to wait releasing it until the next master version is complete. If you have a chance to test out ProcessWire 3.0.183 on the dev branch, please let us know how it works for you, and especially if you run into any issues. Thanks for being here and have a great weekend!
  22. This week we have 12 new commits to the dev branch largely focused on resolving older issue reports. Since the focus right now is primarily on getting the next master version live, we'll likely keep this focus for the next week or two, making sure the next big release version strikes the best balance between new features, issue resolutions and timeliness. Thanks for being here and have a great weekend!
  23. ProcessWire 3.0.182 is now posted on the dev branch. For a review of what's in this version, see the "Latest core updates" section of ProcessWire Weekly #374 and #375 plus this week there have been 12 additional commits with new issue resolutions, improvements and additions which can be found in the dev branch commits log. It's possible that ProcessWire Weekly #376 will also cover some of these updates when it is released too. I'd planned on even more in this version, but ended up losing a day of work yesterday as we had no electricity all day (it happens). So I worked outside in the yard instead— 3 issues were resolved, 4 improvements were made and 1 garage was organized. Focus in the coming weeks is on our next main/master version (core, not yard). If you have a chance, please take a moment to add sites you've built with ProcessWire to our sites directory. And if it's one that's already in the directory, feel free to add it again when/if it goes through a major redesign or redo. I'm really motivated by seeing the great work that all of you do and always enjoy seeing more of it. Plus, I'm thinking @teppo also likely looks at the newly submitted sites when considering the site of the week for his ProcessWire Weekly issues. If you find the existing categories on the submission form don't quite match a site you want to add, please send me a PM to let me know and I may be able to add new categories. Thanks for reading and have a great weekend.
  24. This week has been a continuation of last week in terms of ProcessWire development. While a lot of work has been done, there's not much new to report relative to last week, but I like to check in and say hello either way. I enjoyed putting a lot of time into the PagesSnapshots module this week and it's coming along nicely, getting closer every day. Today I've focused primarily on resolving GitHub issue reports, and am going to keep doing that every week till our next master version, which I hope to be ready in 2-3 weeks (same for the new module). But we'll adjust as needed. The next master version is going to be really solid, so I'm getting excited about it. I will likely bump the dev branch version to 3.0.182 next week. There were a couple more minor issues I wanted to get resolved in 3.0.182 but needed to spend a little more time with before I commit to the dev branch. Thanks and have a great weekend.
  25. While the version remains at 3.0.181 this week, there have been several core updates committed to the dev branch containing a mixture of issue fixes, new features, core optimizations and upgrades. This is likely to continue for another minor version or two while we prepare for our next master branch release. The most visible improvements this week can be found in ProcessField and ProcessTemplate (aka Setup > Fields, Setup > Templates). The main list of fields (Setup > Fields) has been improved with some new supported icon indicators that now identify fields that have template overrides/context settings, among others. All of the existing icon indicators have also been updated with contextual links so that clicking them takes you to the relevant part in the template editor. My favorite update here though is that the "Type" column in the fields list now indicates the Inputfield type in cases where it matters. For instance, rather than saying "Textarea" for the "body" field, it now says "Textarea/CKEditor". Likewise, Page and Options fields indicate what kind of input is used (i.e. "Page/AsmSelect" or "Options/Checkboxes"), as do some other types. Clicking on the "Templates" quantity now takes you to the "Add/remove from templates" field, rather than just showing you a list of templates. Similar updates were made to the ProcessTemplate main list of templates (Setup > Templates) though there wasn't as much to do there. Once you are actually editing a template, the instructions on the "Basics" tab have been improved to clarify what you can do on this screen. For instance, many don't know that you can click a field name/label to edit it in context, or that you can click and drag the percent indicator to adjust the field's width in the editor, all from this tab in the template editor. Now the description outlines these features. When you select a new field to add to your template, it now reveals a note that clarifies you must save before the field becomes editable in the context of that template. These are minor updates, but combined I think they add significant clarity, especially for new users. Stepping outside of the core, I've been working quite a bit this week on the PagesSnapshots module I told you about a couple of weeks ago. It lets you save or restore snapshot versions of pages, and it doesn't have any notable limitations in terms of fields. At this stage it is working fully with repeaters, matrix repeaters, nested repeaters, Page Tables and even paginated Table fields with thousands of rows. It can restore to the original page, to a new page, or to another page of your choice. And it is very fast. Eventually ProDrafts will use its API to handle saving and publishing of draft versions. Initially I plan to release it in one or more of the existing module sets (like ProDevTools or ProDrafts or both), and longer term it may be added to the core. I've got another week or two of work to cover with it, but at this stage the API is fully functional and working well, so I'm now beginning to focus more on the Process module (user interface) side of it. Thanks for reading and have a great weekend!
  • Create New...