Jump to content

Kiwi Chris

Members
  • Content Count

    143
  • Joined

  • Last visited

  • Days Won

    1

Kiwi Chris last won the day on November 13 2017

Kiwi Chris had the most liked content!

Community Reputation

216 Excellent

About Kiwi Chris

  • Rank
    Sr. Member

Profile Information

  • Location
    New Zealand

Recent Profile Visitors

1,460 profile views
  1. ListerPro extends the Lister class, so it's a superset of functionality of Lister, so any bugs in Lister probably also apply in ListerPro. API reference for both is here: https://processwire.com/api/ref/process-page-lister/ I've found the upgrade to ListerPro well worth it, however if you're prepared to write your own modules some of the things it provides like saved lister layouts can easily be achieved with Lister, with minimal coding. I've used ListerPro to export (to CSV), but not to import. I wonder if the issue here is that has_parent is referring to the page id field rather than the title?
  2. An SQL "expert" with records with duplicate keys? That starts alarm bells ringing for me. Generally any SQL table should have a primary key which by definition must be unique for each record. Of course it's possible they have some sort of composite key based on multiple fields that needs combining to correspond to a unique page name in ProcessWire. There are certainly cases where I've build SQL tables with composite keys, with one scenario being many-many relationships, and that's something that Processwire doesn't handle too well, although there is a module that makes many-many type relationships possible, although it doesn't compare to what you can do with pure SQL. Processwire does handle One-Many relationships fine via page reference fields or Pagetable fields. If you really must have a direct relationship between SQL commands and table structure and your CMS, I actually wonder whether ProcessWire is your best option. I've been doing a bit of investigation of Directus which looks promising, although it's headless, so no templates for output like ProcessWire, just a REST API, from what I can see, no full text indexing, and being more of a direct SQL - CMS mapping, it also lacks the hierarchical parent-child structure that ProcessWire handles so well, as it doesn't make any assumptions about what sort of data structures you have, whereas ProcessWire, while generally very un-opinionated does treat everything as a page in a page hierarchy. For websites, that's generally a pretty reasonable assumption, but if you really don't want that, and just want pure SQL tables then there are alternatives. While something like Directus will give you a direct SQL to CMS mapping, it won't fix bad SQL data, so if you've already started down the ProcessWire path, you want to be really sure it's worth the effort to change. I come from a pure SQL background myself, and it only took me about 20 minutes of reading the ProcessWire documentation to understand how it works, so I don't think it should be hard for someone from an SQL background to adapt. Maybe there's room for a blog post or tutorial showing how to "do it this way in SQL" and ProcessWire equivalent along with what's different.
  3. Apart from working with ProcessWire, my other area of work is SQL databases, where I tend to have nearly all application logic contained in the database through views, stored procedures, user defined functions, triggers etc, so I understand how coming to ProcessWire can take some getting used to. If you simply want to import data from an existing system, then there's no problem to mix SQL queries in PHP and calls to the ProcessWire API to read data from an existing database using PHP's PDO or ODBC abstraction layers and then store fields to ProcessWire fields. I've done this myself before importing data from another system, and it's not overly difficult. Here's a bit of code I wrote a few years ago to import some data from another system into ProcessWire. Obviously the SQL will vary depending on what system you're importing from, and how you've named your ProcessWire fields will be different. This is old code, and untested, although I think it worked at the time. Having the Tracy Debugger module installed is a must have, as it provides a PHP console with code completion for the ProcessWire API, so that you can run ad-hoc bits of PHP code to do stuff like importing data without having to write a module or embed it in a template if it's just one off code that will only be run once. $webpressiondb = new PDO('mysql:host=127.0.0.1;dbname=mol_webpression', $user, $pass); $sql = "SELECT {$site}_docs.docid, {$site}_docs.parentid,custhead, subindex, title, keywords, author, {$site}_docs.modified, created, wbdesc, name, content, template, folder FROM {$site}_docs INNER JOIN {$site}_pages ON "; $sql .= " {$site}_docs.docid = {$site}_pages.docid ORDER BY {$site}_docs.subindex"; $wbdocs = $webpressiondb->query($sql)->fetchAll(); foreach ($wbdocs as $record) { //Need to allow for old records with no title. if (preg_match("/[a-zA-Z0-9]/i", $record['name'])) { print '<h1>' . $record['title'] . '</h1>'; $pwpage = new page(); $pwpage->parent = $pages->get($parent); $pwpage->template = $templates->get("rosina"); $pwpage->title = $record['name']; $pwpage->text3 = $record['title']; $pwpage->text1 = $record['wbdesc']; $pwpage->keywords = $record['keywords']; $pwpage->textHtml1 = $record['content']; $pwpage->wid = $record['docid']; $pwpage->wparent = $record['parentid']; $pwpage->worder = $record['subindex']; $pwpage->wcreated = $record['created']; $pwpage->wmodified = $record['modified']; $pwpage->custhead = $record['custhead']; $pwpage->save(); } } If you have cases where you really need traditional SQL tables with multiple fields in ProcessWire, you can create your own custom fieldtypes to do this, but you need to think carefully about whether you need this. The ProcessWire approach can be slow at bulk inserts, as each field results in a database INSERT statement, however retrieving data, especially if you don't need all fields is fast as it doesn't need to load fields in a query if you don't use them. If you're going to be doing a lot of multiple field inserts on an ongoing basis, and you're also going to want to retrieve most or all of the fields when you read the data, creating a custom fieldtype that's a traditional SQL table might give you performance advantage, but to date, I've generally found I've been able to work within ProcessWire's way of doing things.
  4. @adrian Thanks, that's working as expected again now.
  5. I'm having an issue with PW 3.0.163 and this module 1.1.12 where the initial option to send welcome message is not present, however the 'Re-send welcome message' option is present after saving a user. I think I used an earlier version of the module that didn't require the user to have the permission edit-profile, and that worked OK. I think the permission profile-edit is not being set until after the user is already published, so the initial option to send the welcome message is never shown.
  6. I've been running MariaDB 10.2 on CentOS with Plesk for a while, and I don't think I recall any issues.
  7. I've just noticed an issue thats cropped up before in other modules: Processwire allows mixed case field names, however they are always converted to lowercase in mySQL. If you use a mixed case field name eg in addColumns(['mixedCase']) you will get an SQL error, but if you do addColumns('mixedcase') you get no error, but a column of data with Field Not Found as contents. Changing this line in Rockfinder3.module.php seems to fix it: // add this column to columns array $colname = (string) strtolower($column); I'm about to see if I find any other instances.
  8. That's quite a timely update. Just this week I've been working on a site where there are a lot of selectors that depend on various levels of parent/child relationships, and I was wondering about performance, so if this area of Processwire has had a big performance improvement it's very well timed.
  9. The selector in the following code included in a template is returning nothing, however if I take out the compId.resultsdate<={$today} bit, it works fine, although obviously not filtered on the date field. $today = strtotime(date('Y-m-d')); $setImages = $pages->find("template=competitionImage, compId={$page->id}, compId.resultsdate<={$today}, compSubject.name=s, imageRating.title=Merit|Honours,check_access=0"); Here's the results of an example from Tracey Debugger templates_id=79, resultsdate<=1587729600, status<2048 SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_resultsdate AS field_resultsdate ON field_resultsdate.pages_id=pages.id AND (((field_resultsdate.data<='2020-04-25 00:00:00' ) )) WHERE (pages.templates_id=79) AND (pages.status<2048) GROUP BY pages.id Over in my ready.php I have inside a hook that refers directly to the page template that's used for the pages in the page field above: $today = strtotime(date('Y-m-d')) $event->return = $event->pages->find("template=competition,eventEnd>={$today},eventStart<={$today}"); In this case the filtering on date fields (albeit different ones) works fine. Can anyone suggest why the filter on the date subfield of the page field isn't working? Just to confirm, I do have a date value in the field, and it is a date before today. 🙂 The problem may be something blatantly obvious, but I can't for the life of me figure out why the selector is returning no results when I include the date filter.
  10. I only have one kid, so in some ways that keeps things easier, although she's in the office with me on the other PC which can make things interesting at times. We are allowed out walking as long as we keep to our neighbourhood and stay a safe distance from other people. Things have been pretty relaxed up until Sunday when the oven died, which made things a bit more inconvenient as we've been doing a lot of home baking, but that is out of the question now until I can get someone to repair it, or buy a replacement, which either way looks like at least a week away. At least there's a good chance of eliminating the virus completely here within the next few weeks, which will allow life to return to some semblance of normal, but the borders will likely be closed well beyond the end of the year.
  11. @adrian, thanks, I've got it sorted. It was a typo in a field name on my part. I didn't realise it would drop the whole filename pattern rather than just the incorrect part, but once I corrected that, it's all good.
  12. I'm trying to use this module, but currently no renaming is happening, either on upload or after save. My rule is : {$page->compGrade->title}_{$page->compSubject->title}_{$page->compMedium->title}_{$page->title} $page->compSubject and $page->compMedium are Options fieldtype. I get for example: imgp0887_upload_tmp.jpg which is definitely not right. I'm on PW 3.0.144 There's not by any chance an issue with the module not handling mixed case field names? Processwire itself does allow mixed case field names, however I've struck several modules including from Ryan himself, that convert everything to lowercase, to match database table names. That's the only thing I can think of that might be causing renaming not to work. Here's screenshot of configuration below:
  13. Will the custom PHP code option work with multiple statements? I have a tree structure like: Members -Member 1 -page 1 -page 2 -Member 2 Competitions ... I want to restrict logins with role member to just their own member branch, and that works fine currently with: return "/members/" . ($user->name); What I'd like to do is if a login has the role 'membership-secretary' set their branch to Members, and then any other admin roles to home, as I can use template permissions to prevent them accessing parts of the site they shouldn't, but I'm trying to make it easier on the 'membership-secretary' role so they only have to see the branch of tree they'll work with. I understand the module doesn't support restricting to multiple branches simultaneously, but I don't think that's what I'm trying to do. I only want to grant access to a single branch to a given user, however depending on their role, they will have access at a different level in the page tree. I had a go with if($user->hasRole('competition-secretary') || $user->hasRole('membership-secretary'){return "/members/";}else if($user->hasRole('member'){return "/members/" . ($user->name);}else{return "/"} statement, but that caused a 500 error, so I'm just checking whether this kind of use case scenario is possible?
  14. One thing to remember with Processwire is that while the default behaviour, and that of most built in fieldtypes is to use one table per field, like with most things, Processwire is incredibly flexible, so if you have a use case where a single table with multiple fields will be a more efficient way to store and access data, Processwire supports that too through custom field types, and indeed their are some built in fieldtypes that actually do work this way, such as map markers. Profields also includes a table fieldtype which as it sounds, is a database table with multiple fields. It takes a bit of work to write a module to provide a custom fieldtype but there are examples in the modules directory such as fieldtype Events which is specifically intended as an example of how to make a fieldtype that corresponds to multiple database fields. https://modules.processwire.com/modules/fieldtype-events/ In answer to the question, "Is the Processwire database structure scalable", I'd say that's entirely up to the developer, as you can really choose whatever database structure you like, just it takes a bit more work if you want to store multiple fields per table, and usually the built-in fieldtypes and default behaviour works fine. Where I have noticed there can be a little bit of a performance hit is doing a large import from CSV where each field from the CSV file results in a separate insert operation to a different table, whereas with a traditional database table with multiple fields would result in just a single insert operation per record, and potentially fewer indexes to update as well. If you're doing single page additions via the backend, via user interaction, Processwire is plenty fast enough, and there are performance gains to be had at the read level if you don't need to read every single field from a page every time it's accessed in front end templates, eg building a menu, you probably only want title and url, so reading the entire page content as well is unnecessary overhead, but if the content is in a separate table, and you don't access it, you don't have that overhead. There are always performance tradeoffs, but I think Processwire has struck a good balance. A default that works well for most people, but the means to do things differently if you really need to.
×
×
  • Create New...