Jump to content

Kiwi Chris

Members
  • Content Count

    147
  • 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

223 Excellent

About Kiwi Chris

  • Rank
    Sr. Member

Profile Information

  • Location
    New Zealand

Recent Profile Visitors

1,531 profile views
  1. Since I first rebuilt this site in Processwire, it's had a major overhaul, with all competition data now handled on the site rather than in a separate desktop database app. Members are able to access the admin, but using AdminRestrictBranch, some hooks in ready.php and some custom process modules, logged in users are taken to a dashboard that varies depending on their role, so members can only see their own competition images (in a list via Lister Pro) and submit more, while the competition administrator has a dashboard that allows them to manage all aspects of competitions. Competitions close off automatically once their closing date has passed. CustomUploadNames module is used to automatically rename image files when they are uploaded so that once competition entries are downloaded as a zip file, they can be identified by filename. On the front-end slideshows are generated automatically once competition results have been entered, which is done via Lister Pro.
  2. It's possible to hide the page tree, and redirect users on login to some other page. Lister Pro allows you to create your own pages that show data in custom table layout that are editable, and it's not too hard to create your own admin dashboard module with links to several listers. Here's a thread with some discussion of both:
  3. 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?
  4. 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.
  5. 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.
  6. @adrian Thanks, that's working as expected again now.
  7. 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.
  8. I've been running MariaDB 10.2 on CentOS with Plesk for a while, and I don't think I recall any issues.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. @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.
  14. 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:
×
×
  • Create New...