Kiwi Chris

I'm starting to think the issue isn't with the website at all, but possibly the domain, as the webmail subdomain which points to a different IP address, and is managed by the web hosting provider is also flagged as unsafe, so it looks as though Google has blacklisted the entire domain and subdomains.

As of this morning, the mail server for the domain is also blacklisted by Microsoft, and that's a different IP address again.

It's shared hosting, so I wonder whether some dodgy WordPress site on the server has been compromised and started sending out spam resulting in all services from the same provider getting blacklisted.

I'm not sure that this is necessarily security, although Google thinks it is, but I'm interested to hear if anyone knows what triggers it.

I have a website that's triggered in the last 24 hours (I was on the site last night no problem) a big red warning from Google when you access the URL in Chrome: Deceptive site ahead

In Google Search Console, I'm told the site has deceptive pages, although Google won't give me any sample URLs to figure out where it's happening.

Quote

 

These pages attempt to trick users into doing something dangerous, such as installing unwanted software or revealing personal information. Learn more

When I click for further details, I'm told "Social Engineering Content detected on site ..."

I can't figure out what Google is determining to be 'Social Engineering Content' as the site looks fine in Edge or Firefox (running in Windows Sandbox just to be safe).

Has anyone else had this issue, and if so, do you know what triggers Google to classify a site like this?

With latest stable or later version of ProcessWire, PHP 7.4x I'm getting error: 

Call to a member function getDefault() on null 

841:            $langName = $this->wire('languages')->getDefault()->name;

I don't have multi-language support installed so I'm not sure if this has anything to do with it?

6 minutes ago, MarkE said:

The sequence is: remove (pages > templates > fields); add/change (fields > templates > pages). Within each type (e.g. pages), the sequence is in the order listed in the entry.

I think this caters for most situations - e.g. a new page select field followed by a changed template, followed by pages in the right dependency order - but it may not cover everything (particularly making the uninstall happen correctly too).

Where this may not work is where you have a new page reference field that needs to access pages with a given template when that template does not yet exist, or a given parent page when that parent page does not yet exist. In that case you're going to need to add a page or template (or both) before you add the field.

@adrian mentioned having to loop through several times to ensure all dependencies are met, and I don't think it's possible to avoid this.

Some field types don't have dependencies, so it makes sense to process them first, but page references will have dependencies that may or may not have been met, and if not, you'll need to install any templates and pages then loop back and check whether the page reference fields have their dependencies met.

Where it gets really messy is if you have a template that depends on one page reference field, which happens to be the template used by another page reference field.

eg: customer->billing-contact (page reference to contact template) , invoice->customer (page reference to customer template), so invoice template can't be made till customer page field exists, which in turn depends on template that has a page field that references contact template. In this case adding fields > templates > pages in that order won't work.

FWIW, it's hard to make dependency tracking work, and even the big guys have issues. I recently had a .Net Xamarin Forms app project using Microsoft Visual Studio, and circular references between dependencies between third party libraries was blocking me from updating what I needed to get it working. In the end I had to delete all the dependencies and then add them back in with the updated versions to get it to work! 

I think what I'd be happy to settle for as a developer with ProcessWire, would be to be able to set up a single list of objects in order, specifying whether they're a page, field, template, or module, etc with the ability to reorder them if necessary, similar to in the template editor you can re-order fields. Although this means I'd need to manually figure out what order things should be in, if I'm creating the code, even if it's via ProcessWire admin rather than the API, I should know what depends on what.

It might simplify the layout of your UI a bit, as you'd simply have object type, object name, whether to add/update or remove it, although it would require some ajax callback if you want a lookup on the list of objects to make sure the object with the name you've specified actually exists as the type you've specified, although maybe not absolutely essential as currently you've just got a text field to add your object names.

A question: Do new and changed fields and/or pages get processed in the order they're specified? 

I'm thinking of the scenario where a new page field is added that depends on a template and page that may also need to be added. That's one of the scenarios where using the built in field inport/export doesn't work too well if there are dependencies. It will advise you of them, but then you have to go back and import the dependencies then re-do the import, whereas if it's possible to specify order so that dependencies are met before an object is processed, it would make migrations more robust. This isn't an issue for declarative development via the API rather than the admin UI, as the developer can order their code so that dependencies are processed in order, but if changes are made via the admin UI this is a potential problem.

On 3/8/2021 at 4:45 PM, adrian said:

Hi @Kiwi Chris - I haven't ever seen that which is strange.

Would you mind doing me a favour and reporting that here: https://github.com/parsecsv/parsecsv-for-php/issues 

Thanks!

I figured out the problem. The hosting control panel said that PHP 7.4 was installed but it was actually only supplying 5.4. I got that fixed and the module works now.

That works perfectly. It saved me a heap of time trying to figure out what hook to use.

I need to restrict editing access based on both the user role, and the value of a sub-field in a page reference field.

eg $page->competition->closingDate 

There's some discussion about restricting editing access based on role, and that works, but when I try to access the page via the method @Robin S suggests, the page returned is an admin page rather than the page being edited, so I don't have access to the edited page's fields.

@ryan, this module needs to be updated to support import of decimal fields now they're in the core.

I get the following error on attempting to import a CSV file:

Quote

Parse Error: syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' (line 63 of site/modules/BatchChildEditor/parsecsv-for-php/src/extensions/DatatypeTrait.php)

I'm running ProcessWire 3.0.171, on PHP 7.4x 

On 2/25/2021 at 11:27 PM, MarkE said:

I think PW is admirably suited for this type of application - I researched a whole bunch of other CMS/CMFs and nothing came close. The balance of features vs flexibility is spot on. The only issue that irks me slightly is the database vs. code issue - i.e. the database effectively contains business logic as well as data which does create maintenance issues (some careful thought is required as to what logic should be capable of being amended in the admin and what is best to put in the code if possible - for example I moved all Hanna code logic into a separate php script). I suspect the recent debate about front-end enhancements is precisely because PW is seen as a bit more lacking in that department.

I've looked at quite a few other CMS/CMFs and most of them fall down in some respect compared to ProcessWire, whether it be documentation, community, or ease of use. That doesn't make ProcessWire perfect, and given the diversity of usage scenarios there will always be things that could be done differently.

The admin certainly can be a mixed blessing. It's so easy to use, that it's tempting to rely on it at least to start with, but then when you need to maintain changes, it can get complicated.

I think what could be quite nice, if it's possible, would be to have the ability to enable change tracking for templates and fields, when they're modified via the admin. It's already possible to export and import field and template definitions as JSON, so combine this with the ability to track what's changed, and something like @bernhard's migrations module, and it could be easier to combine the ease of using ProcessWire admin to make changes, and the need to be able to roll out changes from development to production sites.

On 2/12/2021 at 9:31 PM, bernhard said:

I'm using ProcessWire all the time for Backend-only applications. Sometimes I also feel like I'm using it in a "wrong" way... But sometimes it seems that there are more people using PW for database applications. I think it is a great tool for such scenarios - I have to admit though that I did not try any others. What's really missing is a way to present tabular lists. That's why I created RockGrid/RockTabulator/RockFinder. RockFinder3 is a great product, while RockGrid/RockTabulator is better than nothing but I'm working on a better solution ? 

I don't get your problem though... What's wrong with a list like this?

@bernhard Thanks for a really helpful example. It's also good to know other people are using Processwire as a full backend application. Thanks also for making RockFinder3, it's a great module.

For non-editable tabular lists, I've just used the core MarkupAdminDataTable that works well enough for my needs, although I should probably build some sort of reporting module so that I can easily define group headers and footers for totals, headings etc. 

1 hour ago, szabesz said:

Since PW 3.0.127 there is the option of setting "Unique" status for pages. Maybe you could utilize that? https://processwire.com/blog/posts/pw-3.0.127/

I'm not quite sure what you are referring to by saying "across multiple fields". Do you need the value of one field to be unique on the very same page compared to another field(s) of the same page, perhaps?

The "Unique" status in Processwire does quite the opposite of what I want.

What I need is to be able to have First name: John, last name: Smith, Address: 10 main street allowed but unique

and also First name: John, last name: Smith, Address: 10 high street also allowed but unique

Address can't be the unique field though because there could be someone else living at the same address, so what makes a record unique is the combination of all three fields. 

This is easy to do in SQL, eg CREATE UNIQUE INDEX person ON members (firstName, lastName, address);

but not quite so obvious in Processwire, although I think perhaps a hook before Pages::added could do a $pages->count('firstName=John,lastName=Smith,Address=10 main street') and if this returns a non-zero value, return an error.

I'm not sure what sort of performance implications there would be doing it as a hook vs in SQL on multiple fields in a table.

1 hour ago, szabesz said:

The page id is an auto-incrementing number. Can't you just simply rely on that? Am I missing something perhaps?

I can write a hook to make the page name the page ID. It's only one duplicate field, and I can rename the display name for title for the templates involved as First Name I guess, as that's always going to be a required field, just not unique.

It doesn't solve the issue around validation of uniqueness across multiple fields, although I guess that can be achieved with a hook before saving, to check whether  $pages->count() > 0 for the field combination I want to be unique.

From recent discussions around the future of Processwire, I suspect my use case might be a bit different to others, as rather than using it in the website 'builder' type scenario, I'm using it more as a database management system, where structured data is critical, and quite often 'pages' will never be visualised via a template, and if they are, the template file is effectively a 'report'.

In my case I'm tending to build sites where the admin IS the site, and there's often little or no front-end. 

I've wondered whether I'd be better to learn some framework like Yii or ASP.Net that have CRUD code generators that can generate data entry forms for SQL tables, but I like Processwire's admin, and the permissions system is something I rely on a lot.

I've started working on a membership app, that will have quite a few users, and I've immediately run into a problem. 

I want admin users to be able to store first name, last name, address etc for members, but it's quite conceivable with a large enough list that it's possible to have more than one say 'John Smith', living at different addresses.

I know how to write a hook to put an arbitrary auto-incrementing number in the title field (which will also populate the name field), but this seems to me to break the DRY principle. There's already a page ID, and if I'm effectively populating two other indexed database fields with an arbitrary number so that I can uniquely identify records and keep Processwire happy, it doesn't feel quite right.

In straight SQL I can use an auto-increment numeric surrogate primary key and create a constraint on multiple columns so I could have as many 'John Smiths' as I like as long as they reside at different addresses, but I'm not sure how I'd go about this in Processwire, as each field resides in its own table.

Perhaps the new Combo Profield @ryan recently released might be have potential for this, as all the subfields reside in a common database table, and there's already some capability to edit the database schema, although I'm not sure if this extends to creating custom constraints? That would be a really great feature, as it would allow defining unique records based on a combination of sub-fields.

The Combo fieldtype is still a fieldtype though which needs to be added to a template with mandatory fields, so I still potentially have page id, name, and title all essentially duplicating each other's functionality as arbitrary numeric fields.

I understand why page name is meant to be mandatory, as a page that has a template file needs to be accessible via a URL, and the page name is part of the routing, however I'm not sure whether it's practical for pages that don't have a template file to simply work off the page ID? What might be useful is a template property setting that can indicate that the id should be used as the name as well, so there's still a 'name' but it's populated at runtime as a reference to the page id. I'm guessing it might be possible to do something like this via a hook?

Nice clean site. Although I'm on the other side of the world, I remember seeing Shetland calendars and other things most years, because in the pre-internet days Mum made a pen-friend connection with a Shetland woman with the same first name as her. I believe the two were put in contact by a publication run by Enid Blyton - yes The Enid Blyton of Famous Five fame.

Mum's never been to Shetland nor has her pen friend ever been to New Zealand, but in our family we've always had this kind of long distance connection. I have an idea that my brother's mother-in-law actually has relatives from Shetland, so the connection there is even stronger.

17 hours ago, ryan said:

Quote

One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you

Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands.

Never say never. When I was 25, I was fit an healthy, and then got meningitis which nearly killed me. When I was 42, I was also apparently fit and healthy, and then ended up with a twisted bowel which also nearly killed me. I've recently been asked a similar question by some of my clients, "What happens if something happens to you?"

I think perhaps a peace of mind option with the pro modules might be to include some sort of clause that allows rights to modify them to provide bug fixes etc, and also explicitly have some sort of clause around what happens if the developer (you) ceases to support them.

I've often thought about software licensing and what should happen if the original author is no longer able to support their code, but there's still a need to use it. I know that people need to earn a living, and relying on donations usually won't be sufficient, so licensing software is a fair way to get paid, however it would be useful to have some sort of commercial license that both respects a copyright holders right to earn an income, but also provides peace of mind to licensees in the event of the software being abandoned by the original creator. I understand in normal circumstances, copyright extends past an author's death, but I know that my wife or daughter would not be able to support any code I might write, although they might need revenues generated by it if it's still useful without modification, so the licensing thing is complex.

40 minutes ago, Robin S said:

Part of the process that happens when you set a Files or Images field value is the copying of the file to the page's folder in /site/assets/files/.

The solution is not to set the Pageimage to the field. Just use some variable name like...

$header_image = getHeaderImage($page);

...or if you want it stored on the Page object then invent some property name that isn't a field name, e.g.

$page->the_header_image = getHeaderImage($page);

 

Thanks. I worked out the first approach which works as a quick fix, but it's good to know the second one will work as well, as I think from an OO programming perspective, it's clearer to use the second option as I am effectively setting a page property, just I'm doing it at runtime, and as a non-persisted property.

Every week or so, I'm finding large amounts of space taken up with orphaned image files on some  pages that have an image field but no images, with the image file names starting with a base number then numbered sequentially. I the worst cases this can amount to several hundred images.

I run code similar to what @ryan posted in this thread: 

however after a few days the large number of files are all back again taking up considerable amounts of space. These are pages that no one other than myself has editing access for. 

The one thing the pages in question have in common is that they do have child pages that have images, and the orphaned files that are duplicated many times are an image that belongs to the first of the sub-pages of the page where the large number of copies are created.

I have this function:

/*
* If a page doesn't have a header image explicitly set, search for the first child page that has a header image, and use that instead.
*/
function getHeaderImage($page) {
		if ($page->headerImage) {
				$headerImage = $page->headerImage;
		} else {
				foreach ($page->children as $item) {
						if ($item->headerImage) {
								$headerImage = $item->headerImage;
								break;
						}
				}
		}
		return $headerImage;
}

And in the templates affected this:

$page->headerImage = getHeaderImage($page);

It appears that every time I assign an image this way, a new copy is getting made into the page's /site/assets/files/ folder even though I never save $page.

Normally with other page properties, if they're set, but never saved, then they don't persist, but I know images may be different as they correspond to actual files on disk.

Is this expected behaviour?

On 1/8/2021 at 6:21 AM, adrian said:

This sounds a bit confusing to me. I feel like we either need a separate decimal fieldtype, or maybe a FieldtypeNumber that has options for all the numeric types that MySQL supports. Of course we also have a separate FieldtypeInteger, so maybe it will start to get confusing if they are all combined into one Numeric type now, although I think it might be the ideal option, although I haven't thought through all the possible issues with this yet.

I agree. The way I see it, if there's a low level SQL type that supports given functionality, there should be a fieldtype that corresponds to it, however the ProcessWire specific fieldtypes are there for when additional functionality is required that can't be supported directly through SQL.

Speaking of that, it may be a bit of a limited use case, but I've wondered a few times about adding geometry fieldtypes and adding geometry selectors. There's already the FieldtypeMapMarker, but this is using just standard float fields in mySQL, while mySQL and MariaDB have support for geometry datatypes and spacial indexes, and there are times it would be nice to be able to do a query and return all the places within a given distance. I already hacked the FieldtypeMapMarker a bit to allow adding KML overlays exported from Google Earth, or mobile tracker apps, but there's certainly a lot more that could be done to give geospatial data first class treatment if enough people use it.

18 hours ago, adrian said:

For this need you should be able to import data from an existing SQL table into a Profields Table pretty easily - either via CSV with the Table CSV Import/Export module, or even with SQL. The other option might be to build a custom fieldtype that utilizes something like http://tabulator.info/ to connect directly to your existing table and manage its content that way. Would that be useful for your needs?

Tabulator looks interesting, although sometimes I want forms, not tables for data input. The trouble with Profields Table is it seems to be geared around having multiple records in a row format per page. If I understand it correctly, the new combo fieldtype stores things in sql fields in a table in the database, but gives more flexibility around layout, and is a single record per page, so this is much closer to what I want, and may be what tips the balance in terms of me buying the ProFields package. A question though is whether this is actually creating separate fields in the database table, or doing what custom image fields does, and just storing a JSON object in a single field. From an SQL perspective, having separate fields and being able to do sorting and grouping at the SQL level would be more convenient than doing it at the PHP level. 

I would like the option that I raised elsewhere around ordinary field types, of being able to choose whether to index subfields or not, as some will only ever be retrieved based on selecting on other fields.

I guess I should bite the bullet and try building my own custom fieldtypes. I'm at the point I'm comfortable building simple Process admin modules thanks to @bernhard and his excellent tutorial on building custom admin modules, however I think a good tutorial on building custom data driven fieldtypes or custom admin data access modules might be helpful, and it might actually be as useful as adding more features to ProcessWire itself, as with all the various inputfields and Process modules, possibly everything I need is already there for custom SQL data, just I need to join the dots.

7 hours ago, adrian said:

The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice.

I'd say this is a biggie. During lockdown here in NZ (thankfully long over), I had the need to move various client databases to the cloud, and started looking at a headless CMS, Directus, because ProcessWire doesn't let you easily hook up an SQL database, leaving the SQL structures alone and just give you an admin UI and API, and yet looking at what Directus does and what ProcessWire does, I can't see why ProcessWire couldn't be made simple to connect to an existing SQL backend. Input Fields work with a wide range of data, and there are already ProFields like Table and Combo that connect to an SQL table behind the scenes, so maybe having a fieldtype (maybe a pro field?) that can connect to any SQL table would be quite handy. That would make connecting to existing apps that have been built outside of ProcessWire straightforward, and also make migrating data simple if it does make sense to pull it into the ProcessWire way of doing fields, as the external data can be accessed via the API.

ProcessWire already has a fields table that contains the definitions for how each field should be managed in the backend, and I guess it should be possible to do something similar linking an existing SQL table, where it is possible to specify any inputfield parameters for each table field, while leaving the actual SQL table alone.

I can see a down side, in that some people who are used to SQL tables, and don't quite understand the ProcessWire way might be inclined to use SQL tables for everything when the ProcessWire way of one table per field actually has advantages depending on the data, but if it makes migration easier, and sticks with ProcessWire's philosophy of trying to keep out of your way and not dictate how you work with your data, then perhaps it could be useful?

For years, as a personal project, I've been documenting my little corner of the globe via my personal website www.marlboroughonline.co.nz, which also gets used as my testbed for new ideas with ProcessWire, SEO and other stuff, as I'm not going to have some client on the phone if I break something, but if I do it well, I can earn a few dollars from Google adsense.

I've always had a bit of a passion for natural history, being introduced to David Attenborough documentaries when I was a teenager, and actually studying life sciences at university, so it's only natural if you'll excuse the pun, that a part of my site would be dedicated to documenting local plant and animal species in my part of the world.

For many years, one of go to reference websites for information about native plants has been New Zealand Plant Conservation Network, and I often include a link from my site to details on a species on the site as an authoritative reference, and I use the site to help identify plants I've photographed. It was only recently that for some reason I decided to have a look at the source code of the site, and it looked suspiciously like it was made with ProcessWire. After a bit more detective work, I found out that it was made by @Robin S and is indeed built with ProcessWire. 

To get away from the computer, I also teach kids edible gardens at my daughter's school a couple of hours a week. It's part of a wider Enviroschools programme here in NZ, and among other things it covers is teaching kids to recognise noxious weeds. There's a really useful website Weedbusters that's supported by councils and used as a reference for many invasive plant species, and it turns out it's more of Robin's handiwork.

I think it's a bit funny that even when I'm supposedly away from ProcessWire engaging in other activities, it seems to follow me around. ?

46 minutes ago, Robin S said:

Hear, hear! ?

One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues

There's also the wishlist and roadmap on the forums here.

https://processwire.com/talk/forum/5-wishlist-roadmap/

@ryan from your perspective do you have a preference where people post feature requests, and is there a reason to use the forum vs github and vice versa?

46 minutes ago, Robin S said:

At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207
I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).

Interesting feature request. I could have used that recently, although in most cases the images I wanted to use were the only ones on the page they belonged to, so I just used a normal page reference and used the image from the page. For pages with more than one image though, it wouldn't work if I wanted to pick a single image.
Now that images support additional fields via a template, then I assume behind the scenes there is a page holding this data, so it should be possible use selectors like with regular pages on these fields to find images that match regardless of what page they belong to? That could apply not only for an images reference field, but also for the RTE when inserting images, to provide an image search functionality, like currently is possible when inserting links.

Since others are getting into localsied greetings, Meri Kirihimete! (Although we're actually already a day ahead and Christmas was yesterday in my part of the world.)