Jump to content

ryan

Administrators
  • Posts

    16,417
  • Joined

  • Last visited

  • Days Won

    1,446

Everything posted by ryan

  1. @joe_g It looks to me like you've got an autoload module that's injecting scripts into your admin (a cookie content module or SEO type module?). Such a module should only be injecting scripts into the front-end, and not into your admin. So I would identify what module is doing that and stop using it, or update it to only load on the front-end. It you can identify what module it is, let me know and I can suggest what to change about it. Likely it's just a change to 1 or 2 lines.
  2. @joe_g In addition to what Bernhard mentioned, I would figure out the location of the prepareInjection.js file at the top of your JS console. That looks like a React file, and I'd wonder why it's loading here. Perhaps it's coming from some module? You should be able to click on it to identify the location, or view your Network tab and find it. You might see it coming from some site/modules/ModuleName/ directory? If so, try temporarily disabling that module to see if that's the issue.
  3. The invoices application site profile that I uploaded last week now has a companion blog post: https://processwire.com/blog/posts/invoices-site-profile/ Thanks for reading and have a great weekend!
  4. @fruid The cache time should be fine. I'm guessing maybe it just didn't work on the first use for whatever reason, and the non-working data was cached.
  5. @fruid Make sure you are using the newest version (version 3). Go to Modules > Site > ServiceCurrencyConversion. At the bottom is a checkbox to "Refresh rate data now". Check the box and save. Now make sure that you see HKD in the table shown on the configuration screen. If you don't, edit your /site/modules/ServiceCurrencyConversion/currencies.txt file and make sure it's in there, adding it if it isn't, and refreshing again. If you don't see any data loaded, I'm guessing that your server is blocking the outbound http request to the exchange rates API. You could modify the module WireHttp call to force it to use CURL or fopen, depending on what your server supports. Let me know if you need help.
  6. @teppo Not very straightforward, but here's a function that would tell you whether or not a translation exists for the given phrase in the given file, in the current language. Maybe we need a dedicated core function for it? function isTranslated($text, $textdomain) { $translator = wire()->user->language->translator(); $translations = $translator->getTranslations($textdomain); $hash = $translator->getTextHash($text); return isset($translations[$hash]) ? $translations[$hash]['text'] : false; } Example $text1 = 'About Us'; $text2 = isTranslated($text1, '/site/templates/about-us.php'); if($text2 === false) { echo "Not translated: '$text1'"; } else { echo "Translation of '$text1' is '$text2'"; }
  7. This week the new ProcessWire Invoices site profile has been released on GitHub here: Invoice Application Site Profile. This particular profile is much broader in scope than the others I've developed for ProcessWire, so will benefit from more descriptive information about what it includes, how to use it and modify it, and how you might build further from it. That info will all be coming next week in a new blog post. But feel free to download and install the site profile sooner if you'd like. If you are already familiar with ProcessWire, then perhaps most of it will be self explanatory. While this site profile doesn't cover everything that you might do with an invoicing application, it does cover everything that I've needed over the last year of using it with my clients. Though admittedly, I don't have a lot of clients, nor do I send a lot of invoices. Given that, when my existing invoicing service raised the monthly rate from $3/month to $20/month (a year or so ago), that's what motivated me to build this site profile. And it does everything my previous invoicing service did, and in fact does it better. While much of it was built several months ago, major improvements have been made to it over the last couple of weeks, preparing for it for release as a ProcessWire site profile. My hope is that you'll find this site profile easy to work with, and easy to build out further where needed. For instance, I imagine some may want to add in the ability to pay an invoice. It would be relatively simple to add in FormBuilder with its Stripe Processor plugin, or perhaps some other payment solution. But all my clients pay by check, whether physically or digitally, so I've not needed to add payment ability to the application yet. In any case, I hope that you find this site profile useful, and please let me know if you run into any issues with it or have suggestions for future upgrades to it. Thanks for reading and have a great weekend!
  8. @hellomoto It looks to me like you can drop the use of DatabaseQuerySelectFulltext. I don't see any text columns or fulltext indexed columns in your query, and I don't think it's doing anything at present. That DatabaseQuerySelectFulltext class is primarily for doing partial matches on text columns, most often using MySQL's fulltext indexes. Your schema doesn't have any columns that would typically be used with this class, and I don't see any indexes on the columns. Currently I'm wondering if you even need a getMatchQuery() method? Your schema is pretty simple, and it seems like the core Fieldtype::getMatchQuery() should handle it fine. If not, can you give me an example of a selector that is not working? (remove or comment out your getMatchQuery method completely to test). The only thing I can spot in your schema that confuses me is the CHAR column with no length specified. I've only ever seen CHAR(n), where n is the fixed length of the CHAR column. Would "CHAR" be the same as CHAR(0), which either holds a 0-length string or a null? If so, then this may be a reason to have your own getMatchQuery, as PW consider blank string and NULL to be the same when querying the DB. So a simpler solution might be to just change it to a TINYINT, CHAR(1) or ENUM, so that you can be explicit about the ON or OFF (1 or 0, etc.) value, rather than trying to distinguish between two empty values (blank vs. null). Then it should work with the core getMatchQuery. The sf1 and sf2 columns may need to be indexed for best performance though.
  9. There are a few commits on the dev branch this week, but nothing particularly notable. I had to do some client work this week but also ventured back into the Invoice site profile, which I mentioned quite awhile ago, but hadn't yet released. I'm hoping to finish that up and release it as another site profile option for ProcessWire very soon. Perhaps as soon as next week. I had originally planned on building out that Invoice site profile quite a bit more, but having used it for my own invoices for many months (maybe a year?), I think it's better to keep it simple. Otherwise I'd be making assumptions about what others might need. Even in its relatively simple state, it suits my own needs well. And I think if it gets more complex, then people are less likely to explore and modify it, making it less useful as a site profile. The site profile is also simple enough right now that it doesn't need to be a Pro module or need Pro-module support. Since we don't have a lot of site profiles to choose from, I'd rather keep it free. It is admittedly more of a mini application than a website, which is why I think it might bring some more diversity to the available site profiles. Chances are it won't replace whatever invoice service you might be using, but I think it's still pretty useful, whether using it to create invoices, or just using it to explore more of ProcessWire. More next week. Have a great weekend!
  10. @hellomoto It looks like you are building a custom Fieldtype? If so, can you paste in the contents of your getDatabaseSchema() method? Matching an empty value can depend on the schema, though usually is handled by an OR condition that matches an empty string or the non-presence of a row. Matching the non presence of a row is done by performing a LEFT JOIN on the field_* table along with a WHERE condition that matches "IS NULL field_table_name.pages_id". It can be a little tricky, so luckily PW handles this situation for you internally, and doesn't require your Fieldtype to handle it unless you tell PW that you want it to… To describe further, ProcessWire matches empty values automatically, and so may not even call your getMatchQuery() for most empty-value matching selectors. But if PW isn't correctly matching it for you, then you may need to implement your own "empty" match logic. PW asks your Fieldtype::isEmptyValue() method (if implemented) if you would like to handle that situation (details). If it sends a Selector object to your isEmptyValue() method and your method returns true, then you are telling PW you want to handle matching the empty value: public function isEmptyValue(Field $field, $value) { if($value instanceof Selector) { // tells PW your getMatchQuery will match empty values return true; } return parent::isEmptyValue($field, $value); } So if you have a method in your Fieldtype like above, then your getMatchQuery() would have to have logic to match an empty value. I don't think your current getMatchQuery() would correctly match an empty value, so I'd need to see the schema to identify what would be needed.
  11. @diogo PAGEGRID also looks amazing by the way. I don't have much experience with page builders, but it seems like PAGEGRID is really well thought out and does everything you could want.
  12. @diogo @jploch Wow that is awesome! It's completely different than anything I've seen before. It's really fun to scroll through too. I'm curious about the development side, how do you take over the scroll behavior in that way? If I view the source, there are two completely separate <html> documents in the output, how is that possible? 🙂
  13. On the dev branch this week we have a good collection of issue fixes and feature requests. The dev branch commit log has all the details. One feature added this week which I think could come in very handy is #520 (via @Jonathan Lahijani) which adds the ability to hide individual images in an images field. When an image is hidden, you can see and work with it in the admin, but it gets removed from the field value on the front-end of the site at runtime, effectively hiding it. I know I'll use this a lot, particularly on photo galleries where I may want to remove an image or two from appearing in the grid of photos, but don't necessarily want to delete them. Images can be hidden (or unhidden) from the Actions select of each image, where you'll see a "Hide" option (or an "Unhide" option if the image is already hidden). Hidden images are also dimmed out when viewing the images field in the admin. On the API side, you can hide or unhide images and files using $image->hidden(true) to hide, $image->hidden(false) to unhide, and $image->hidden() to get a true or false as to whether or not the image is hidden. Though this will only be useful on unformatted field values, since hidden images are automatically removed from formatted field values. The same can be used with regular file fields, but we don't currently have a UI/interface for hiding or unhiding items from regular (non-image) file fields. Likely we'll add one soon, but I figured it's likely to get more use with image fields than file fields, so figured we'd start there. More next week. Thanks for reading and have a great weekend!
  14. This week continued the addition of new feature requests and PRs, and the version number has been bumped to 3.0.236. In fact, the addition of feature requests is the theme of version 3.0.236. My favorite addition for this week is probably feature request #474 which adds support for opening and collapsing family groups of repeater items together as one. To enable, see the field "Details" tab setting in "Repeater depths/indents" > "Open/close items as a family?". The same commit also made it possible to disable the automatic scrolling to new repeater items when you click the "Add" button, should that suit your need. Both of these updates also apply to Repeater Matrix as well, but don't require a Repeater Matrix upgrade. More updates can be found in the dev branch commit log, and ProcessWire Weekly has great coverage of what's new with version 3.0.236 in issues #507, #508 and #509. Thanks for reading and have a great weekend!
  15. I've always enjoyed PHP, but never really enjoyed Javascript until I started using jQuery. I continue to enjoy using jQuery much more than vanilla Javascript. Using jQuery has not always been about filling in a gap of Javascript so much as it has been about preferring and even enjoying the interface. It’s fun to use, and Vanilla JS not as much, at least to me. PW has some of its API inspired by jQuery, and together they have always felt just right. When it comes to open source stuff, I like to focus on tools that I enjoy using, as that's what keeps me interested and keeps me going. If we were to take jQuery out of the admin, it would be a huge amount of work, and then leave something that would be less interesting to maintain. So I’m not so enthusiastic about taking jQuery out of the admin. Where I would be enthusiastic about it is with front-end modules that might currently be using on jQuery and don’t necessarily need to. Take FormBuilder and LoginRegisterPro as examples (though there are many more). Perhaps those modules don’t need to require jQuery unless one of the Inputfield modules in use requires it. That way, modules like that aren’t introducing jQuery in an environment where it might not otherwise be in use. And maybe there are some Inputfield modules that currently use jQuery and don't need to. Since Inputfield modules can be either admin or front-end, it makes sense to use vanilla JS when possible with those. So yes, I'm all for reducing or removing the use of jQuery in spots, but not so interested in removing it from the admin.
  16. @ryangorley Nice work, great sites! Would you consider adding them to the sites directory? https://processwire.com/sites/submit/
  17. Like last week, this week the focus has been on adding feature requests from our processwire-requests repository. Though I'd like to give it another week before bumping up the version number. Rather than repeating all that was added here, please see the dev branch commit log, which covers them all, several with more detailed notes in the commits. The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. I was excited to see the new jQuery 4.0.0 release this week, which we'll no doubt be upgrading soon (or once out of beta). Here's a quote from the intro of their new post: Some parts of ProcessWire's API were originally inspired by jQuery. It's always nice to see progress there with new versions, especially a new major version. Thanks for reading and have a great weekend!
  18. This week I was wrapping up the client project I mentioned last week (just launched today here), but did get some updates added to the core as well. Primarily the addition of some smaller feature requests. One of the features added is a README.md and CHANGELOG.md viewer to each module's configuration/info screen. When a module has one of those files in it, it is now viewable from within the admin. You'll see the links them at the bottom of the "Module information" section of any module's config/info screen in the admin. Other requested features added were: Support for OPTIONS, CONNECT and TRACE methods in WireHttp. And, A new hookable method in ImageSizerEngineIMagick added via a PR from Robin S. Support for <hr> elements has been added in InputfieldSelect and InputfieldSelectMultiple. It was news to me, but apparently <hr> (horizontal rule) elements are now supported by browsers between <option> tags in <select> elements, rendering a nice separator between options when you want them. So our Select inputfields now support that. To add a horizontal rule/separator, just add an option with 3 or more dashes/hyphens. Programmatically you would do a call like this when you are between options where you want the <hr> to appear: $inputfield->addOption('---'); Or, if specifying options as text (as you would with Options fields, or several other Fieldtypes), you would just enter a line with 3 or more dashes on it, and nothing else. So if we had an select where you could select a color, and we wanted to separate RGB from the other colors, we could do this on its configuration screen: R=Red G=Green B=Blue --- O=Orange P=Pink C=Cyan Thanks for reading and have a great weekend!
  19. I hope you all are having a great week! I don't have much to report in terms of core updates this week, just a few commits to the dev branch, but with more on the way next week. I'm in the process of wrapping up a client project this and next week, so have had to dedicate more time to that work this week. Though I'll be back to more major core updates and Pro module updates after next week. Have a great weekend!
  20. This week on the dev branch is ProcessWire version 3.0.235. Relative to the previous version, this one contains 19 commits of fixes and feature additions (see commit log). As mentioned last week, this version adds support for custom repeater page classes. Another significant addition was the upgrade from TinyMCE 6.4.1 to 6.8.2, which covers 13 TinyMCE versions with hundreds fixes, improvements and additions (see TinyMCE changelog for all the details). I did also try to upgrade CKEditor to the latest version (which is also the final open source version of CKEditor 4), but found it was making outbound http requests to ckeditor.com, so I reverted to the previous version. Presumably that was just to preform version checks, but what's the point if it's the final version ever... previous versions didn't do that. It also seemed like it could be for some kind of tracking, so I decided to leave it out for now and revisit it later. Lastly, this dev version of ProcessWire adds an improvement to the ProcessWire installer. Now you can choose either "hostname" or "socket" as the DB connection type. Depending on what you choose, it'll provide the appropriate inputs. Previously the installer did not support a socket DB connection option. Thanks for reading and have a great weekend!
  21. @Jonathan Lahijani Good idea, I'll add an update to make it use it for that case (and the one Bernhard mentioned). It'll likely be the same location as what you've suggested, except it'll get it from FieldtypeRepeater::getCustomPageClass() instead, since that already has all the logic to determine what class to use.
  22. This week on the dev branch are some fixes and improvements, but we'll likely wait another week before bumping the version number up. Some new hooks have been added to $pages, including moveReady(), restoreReady() and renameReady(), to accompany the existing moved(), restored() and renamed() hooks. There was also some refactoring with the way that some hooks are called from $pages to improve their reliability and cover some edge cases where they might have not been called before. See the dev branch commit log for more. The biggest addition this week is likely the newly added support for custom page classes for repeater items. This was added to respond to a feature request initiated by @thetuningspoon and @Jonathan Lahijani let me know about earlier in the week. Here's how it works. If you have a repeater field named "menu_items" then you could create a class named MenuItemsRepeaterPage in /site/classes/MenuItemsRepeaterPage.php, and it would use your custom class rather than the regular RepeaterPage. Though note it must extend RepeaterPage. <?php namespace ProcessWire; class MenuItemsRepeaterPage extends RepeaterPage { // ... } This works with RepeaterMatrix and FieldsetPage as well, since both are derived from regular repeaters. But since both have their own Page classes you'd want to extend their page classes rather than RepeaterPage. In the case of RepeaterMatrix, it uses a class called RepeaterMatrixPage. So if your Matrix field is named "hello_world" then you'd create /site/classes/HelloWorldRepeaterMatrixPage.php: <?php namespace ProcessWire; class HelloWorldRepeaterMatrixPage extends RepeaterMatrixPage {} If you want a custom class for your FieldsetPage field named "seo" then you could create /site/classes/SeoFieldsetPage.php: <?php namespace ProcessWire; class SeoFieldsetPage extends FieldsetPage {} Let's say that you want to use a custom class without using the naming convention and/or file(s) above. You can tell the fieldtype what class to use for its item(s) like this: inclue_once('/path/to/MyCustomRepeaterPageClass.php'); $field = $fields->get('your_repeater_field'); $field->type->setCustomPageClass($field, 'MyCustomRepeaterPageClass'); In the example above, MyCustomRepeaterPageClass would extend RepeaterPage. You'd probably want to do this during the "init" or "ready" state, or at least sometime before you load any items from your Repeater (or Matrix or FieldsetPage) field. If your custom class is not in the ProcessWire namespace, then you'd want to include the namespace in your call, i.e. setCustomPageClass($field, "\\MyNamespace\\MyCustomClass"); If your custom page class is already in /site/classes/, or some other path where it can be autoloaded, then the include_once() line isn't necessary. (API ref pages for getCustomPageClass and setCustomPageClass). Big thanks this week to typneun Designagentur (https://typneun.de/) for posting more than 20 awesome new sites to our ProcessWire sites directory! That made my day. Thanks for reading, more next week, and have a great weekend!
  23. I hope that you all had a great holiday and New Years. This week on the dev branch is ProcessWire 3.0.234. This version contains 6 issue fixes, but the biggest update (and primary reason for the version bump) is that this version updates to the newest Uikit version in AdminThemeUikit. We hadn't updated it in awhile, so it's a fairly major upgrade. I found that it broke some really minor things and I fixed them as I found them. But please let me know if you come across any other Uikit upgrade issues I've missed. While it is a major Uikit upgrade, it was an easy upgrade thanks to the work of @bernhard and changes he made to the AdminThemeUikit module awhile back. Next week there will be more issue issue fixes as I catch up with the processwire-issues repo. There were a couple issue fixes already in progress this week that didn't make it in to 3.0.234 as I ran out of time, but they'll be committed to the dev branch next week as well. Thanks for reading and have a great weekend!
  24. I'm off work this week, so I don't have any new ProcessWire updates, but just wanted to wish you a Happy New Year! Looking forward to a great 2024!
  25. @JayGee Great! glad to hear you've found the module useful. Thanks.
×
×
  • Create New...