Jump to content

ryan

Administrators
  • Posts

    14,727
  • Joined

  • Last visited

  • Days Won

    1,025

ryan last won the day on September 17

ryan had the most liked content!

Contact Methods

  • Website URL
    https://processwire.com

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ryan's Achievements

Hero Member

Hero Member (6/6)

20.5k

Reputation

212

Community Answers

  1. 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!
  2. @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.
  3. 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!
  4. @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.
  5. @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?
  6. @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.
  7. 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
  8. @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.
  9. 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.
  10. 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/
  11. @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.
  12. 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!
  13. 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!
  14. 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!
  15. 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!
×
×
  • Create New...