Jump to content

adrian

PW-Moderators
  • Posts

    11,206
  • Joined

  • Last visited

  • Days Won

    373

Everything posted by adrian

  1. $this->addHookAfter('ProcessPageSearch::executeFor You can see here: https://github.com/adrianbj/AdminRestrictBranch/blob/838858fd36a78df808b7690b4cddcb3a6c25ffa3/AdminRestrictBranch.module#L167-L180 where I have removed items from the search results, but you could easily use array_map to search and replace edit with view links in the returned array of matches. Hopefully this will help to get you going.
  2. Just in case someone else arrives in this thread, this is now implemented in Batch Child Editor: https://processwire.com/talk/topic/6102-batch-child-editor/?do=findComment&comment=149975
  3. Hi everyone, For those of you running the core SessionHandlerDB module, I just committed an experimental fix for the problem of the "Redirect" bar not showing. The redirect bar can be very handy in debugging many things that may otherwise be lost when there is a redirect, so it's been a real shame for those who haven't had it all this time. I discussed the approach of my fix with Ryan and long time ago (I was hoping he might include it in the core) and this was his response to me: Basically what the fix does is when a $session->redirect is called, it now makes the header() call before closing down ProcessPageView. The current PW core behavior is to close it down before the redirect. I don't think it should be an issue for your sites to use this new version because it only makes this change if: 1) SessionHandlerDB is installed 2) The debug bar is enabled #2 in particular means that regular users won't be impacted by this at all - only users with Tracy permission (typically just superusers). However if you notice any problems at all, just add this line to your config.php file to disable it. $config->disableTracySHDBRedirectFix = true; And, of course let me know if you have problems so I can revisit my decision on incorporating this fix.
  4. That's not a PW function, so it must be custom. You could search files for "function e(" or you could install Tracy Debugger and enable the "Template Resources" panel which shows you all custom functions (and variables) and where they are defined.
  5. I have actually used it on an old site that I upgraded to PW 3 and it seemed to work fine. The site isn't really active anymore unfortunately (government budgets and all mean that the program is no longer active), so I haven't checked in a year, but I think you'll be ok. It's a pretty simple module.
  6. From what it looks like, $user is the currently logged in user - this check is outside your functions, so I don't see that this is actually doing anything. The email check looks fine This should also be ok, but remember the issue I mentioned with the first line. This turns off output formatting which is important when saving fields to a page - consider a datetime - you want to save a unix timestamp, and not a formatted string like 14 September, 2017 7:17:11 am Really your call - there are arguments for both approaches. You might actually find things simpler if you try this approach to user pages: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users which lets you set up users with URL accessible pages directly. BTW - a great writeup of your approach here - I am sure others will learn lots!
  7. No problem at all - glad it got things sorted for you!
  8. I really would try upgrading to latest dev first - that wireInstanceOf function adds a lot of extra logic that I assume will take care of things when $type is null.
  9. It looks to me like you are running 3.0.62 (or thereabouts) as line 374 of that file looks like: } else if(strpos($type->className(), 'FieldtypeRepeater') !== false) { I would suggest upgrading to the latest dev and see if that fixes it. The new version uses this instead: } else if(wireInstanceOf($type, 'FieldtypeRepeater')) { Otherwise, we'll need to debug $field (type and name) to see what field is causing it to hang up.
  10. Very nice!
  11. I think you are looking for something like this. You need to be making use of the names of the repeater fields and also referencing the repeater field relative to it's containing page. foreach($l->{$f->name} as $repeater_item) { foreach($repeater_item->fields as $rf) { echo $repeater_item->{$rf->name}; } }
  12. Yep, the old version is linked to in this post: https://processwire.com/talk/topic/7905-profields-table-csv-importer-exporter/?do=findComment&comment=150953
  13. We already have a delete permission: Is that what you are looking for, or referring to something else?
  14. Actually, I just noticed that Ryan is now up to v17 / v18beta - hopefully both of those should also work though. EDIT: just did a quick check with v18 and it looks to be working fine!
  15. @Macrura Sorry about that - I should have a check in there regarding the required version of Table. When Ryan introduced pagination I had to make a lot of changes to support it and decided to no longer support older versions. This commit (https://github.com/adrianbj/TableCsvImportExport/tree/b83df4d13fd18fcb6c4bc8ac467e6ae35cba9711) was the last version to support the older version of Table, so you should hopefully be ok with that one, although please note that I have added some new features (like the ability to select the columns to export) and also some bug fixes to newer versions. I would suggest that you instead upgrade to v15 of Table.
  16. Sorry, I mean a web dev outfit.
  17. @SamC - depending on your needs/preferences, you might also look at these: http://modules.processwire.com/modules/front-end-edit-lightbox/ http://modules.processwire.com/modules/fredi/ https://processwire.com/blog/posts/front-end-editing-now-in-processwire-3.0-alpha-4/#now-all-fields-can-be-front-end-editable and also, Tracy comes with a "User Bar" which you can skin that links to the backend to edit the current page: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127824
  18. @SoccerGuy3 - I wonder if a Modules > Refresh would help with that on your local machine - perhaps the Language Support Page Names modules didn't initialize properly?
  19. Sorry, I was more talking about my post rather than what you guys were posting. I completely agree with your goals for 2018. In fact I am currently trying to convince a Drupal shop to go with ProcessWire. They don't want to touch Drupal 8 and I have an PW advocate on their team, but we both agree that PW needs a more modern look (website and admin theme) to help convince their clients. Unfortunately it's often not enough that things work great, they also have to look great and look like they will work great - the whole "judging a book by it's cover thing" - as devs we hopefully don't do that, but clients will!
  20. On the issue of We're getting very OT here, but I have handled this is many different way depending on needs, but this module (originally by @apeisa and fixed for PW 3 by @teppo can actually be a great starting point for a frontend user interface: https://github.com/teppokoivula/AdminBar You will want to skin it to match your site etc, but it can look and work really well, eg:
  21. That does seem strange. I haven't built many multi-language sites, but I think you should have everything you need and the docs seem to confirm that: https://processwire.com/api/multi-language-support/multi-language-urls/#getting-started Any chance the site is online and I could take a look at the admin for you?
  22. Make sure you have installed the core module: Languages Support - Page Names
  23. To expand on what @AndZyk said - there are two parts to multi-language support in PW. The language packs you have installed are for translating the admin interface. If you want site editors to be able to enter content in alternate languages, then you need to create those languages under Setup > Languages.
  24. Curious what everyone else thinks. Maybe it won't be a huge deal in most cases, but I can see sites with certain header and footer content being cutoff with this design. Have a read of their developer guidelines - yet another thing to consider in our designs: https://developer.apple.com/ios/human-interface-guidelines/overview/iphone-x/ Honestly I think more square corners for the device itself look better and I think the screen should be completely square - I feel like this is stepping back to old TV rounded corners: Note that I don't like the edge of the Samsumg Galaxy S8 either - I feel like it looks weird and I am sure your hands would end up covering the edge of what you are trying to view. Sorry for rambling, but I am curious what everyone else thinks they should be aiming for both esthetics and functionality?
  25. You're in good company - we've all done that one
×
×
  • Create New...