adrian

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.

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.

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!

No problem at all - glad it got things sorted for you!

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.

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.

Very nice!

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}; } }

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

We already have a delete permission: Is that what you are looking for, or referring to something else?

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!

@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.

Sorry, I mean a web dev outfit.

@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

@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?

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!

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:

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?

Make sure you have installed the core module: Languages Support - Page Names

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.

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?

You're in good company - we've all done that one

Great, thanks for letting me know. I just committed another update which fixes the issues you were having with the Captain Hook cache not automatically clearing when upgrading Tracy. It will now clear when you upgrade, install, or uninstall any modules, click the modules > refresh button, or change PW core versions. Also, uninstalled (but not deleted) modules will no longer have their hooks shown.

I might do that sometime when I have more time. On another note, I have just fixed the automatic backup of settings on module uninstall feature. Apparently it wasn't working properly Anyway, I think it's really useful so you know you can easily restore settings after an uninstall - very useful for some of the more complex modules out there.

Hey @bernhard - please try the just committed: 4.3.23