JayGee

Thanks ?. I will check out RockSEO. The thing that has kept us on MarkupSEO to date is the simplicity for implementation and also for clients. Combined with the changes you’ve made previously it’s pretty effective at doing what it needs to. I’ll have a think if there’s anything else that can be done to improve it further.

Hi all, Not sure if if everyone has jumped to SeoMaestro these days but I'm still fond of MarkupSeo and it's still live in many of our sites so I've made a few small but important tweaks based on real world usage. @adrian I've just made a pull request with these changes to your fixes branch in case others find these changes useful: Stopped canonical links from being able to inherit from parent pages: Inherited canonical links could cause problems with search engine indexing whereby you're inadvertently telling Google your new page is the same as another purely because you (or a client) missed the canonical field. So I think it is better for the default to be current page URL if the field is left blank rather than inherit the parent. Implemented handling of relative URLs in the canonical field: You can now use relative URLs in the canonical field for internal links. They will still render on the front end as SEO-friendly absolute URLs, but this way it is easier if you use different domains for testing or if you need to change the site domain. (https://github.com/mrjcgoodwin/MarkupSEO/tree/various-fixes-enhancements)

@Krlos I agree with @bernhard - more detail is required on your constraints to really advise. However we've built a number of data-driven sites using PW in this way and I would say putting all pages of a specific type under one parent is my preferred approach vs nesting in multiple sub-folders. It's also more like a regular database table). You can then just use selectors to filter the output and it makes more sense if you have entities that might apply to multiple parents. E.g. a staff member that works at multiple locations. For those maintaining the site/data you can make it easy on them by configuring the 'family' tab for each template. So for instance, only a 'hotel' can be added as a child of 'hotels'. When an editor wants to add a new hotel they can't then accidentally use the wrong template, or put it in the wrong place. Finding an existing hotel to edit is as simple as tapping the name into the default PW search box.

Yes - Formbuilder has the option to output each form in adherence with a number of popular frontend frameworks - bootstrap included (see screengrab below). There's also a number of embedding options which include the option to completely customise/control the code output so you should be covered from this angle too. Out of curiosity, what are the shortcomings of the default comments you are looking to overcoming. If it's just styling/presentation couldn't you just modify the markup for this instead?

@Goca Are you using a cookie consent management tool by any chance? This potentially could mess with Processwire's cookies if not configured correctly.

Hi all, Can anyone confirm 100% does ProDrafts work with repeater fields? The pro module store page says not, but this update from @ryan says it was added in 2017 - just want to be sure before buying it for a specific repeater-heavy site. TIA ?

I had a typo - missed a '/' off the end of my fields path ? I'll see myself out ?

I'm in the process using PW multisite configuration to centralise a family of sites that will be identical aside from content. I'm trying to create a shared folder for the main site templates and modules. It's all working fine so far but I can't get ProFields Repeater Matrix to play nice. I have my paths set up as follows in config: $config->paths->templates = $config->paths->root . 'shared/templates/'; $config->urls->templates = $config->urls->root . 'shared/templates/'; $config->paths->fieldTemplates = $config->paths->root . 'shared/templates/fields'; $config->urls->fieldTemplates = $config->urls->root . 'shared/templates/fields'; $config->paths->siteModules = $config->paths->root . 'shared/modules/'; $config->urls->siteModules = $config->urls->root . 'shared/modules/'; But the repeater matrix doesn't seem to be picking up the customer templates located in /shared/templates/fields In the template I have the usual: echo $page->render('page_blocks'); ?> But all I'm getting is a bullet point list of matrix block ID's. It's not rendering using the templates. I can force the path of page->render to use the shared folder ($config->paths->fieldTemplates.'/page_blocks.php), but then it just outputs a blank page - as if it's not finding the sub templates. Any ideas? ?

Super excited about the e-commerce projects hopefully becoming ProcessWire shaped!

And on that basis you can signpost people too. So before you allow free type they might have to indicate an initial route by clicking a button - e.g. Do you want a) Report a problem b) Pay a bill etc etc.... "Now tell us which service you want to pay a bill for"...(free type and match). Might help limit the terms they throw at it.

Update.... not 100% sure I'm not overlooking something simple, but I think this may be a bug and have submitted it on GitHub. https://github.com/processwire/processwire-issues/issues/1468

This is a cool idea. And with a JS frontend onto the PW API it would still have a pretty chatesque UX. Plus using PW operators for the page selectors you could probably fuzzy match free-typed enquiries quite well too.

I'm trying to build a search selector that includes a checkbox multiple option field (clinicdetails_specialisms). The whole selector works fine if I don't include the checkbox field. With it included I get errors like "Error: Exception: SQLSTATE[HY093]: Invalid parameter number: mixed named and positional parameters (in wire/core/PageFinder.php line 627)". This is the selector as it currently stands. subscription_status=active,(template=user,clinicdetails_description|clinicdetails_short_description|clinicdetails_clinic_name|clinicdetails_first_name|clinicdetails_last_name*=$query),(clinicdetails_specialisms.title=$query) I've also tried setting the specialisms field in one string rather than groups and have also tried with/without the '.title' property. Oddly the selector works if specialisms is the only field being searched. It seems to fail when mixed with other selectors. Can anyone advise what stupid mistake I'm making!

Could you perhaps solve this by populating your page’s open graph (OG) tags with specific URLs rather then letting them auto populate from the actual link and then using URL segments or parameters to differentiate between real/spider visitors. I think by populating OG tags it will tell fb where to pull the thumbnail, description etc from even if the human visitor has to go through the verification gateway first.

Solved: PHP update reset the memory limit too low.

We have a client's Processwire site where the Pageimage::size() method has stopped working. It's creating small white PNGs in the assets folder instead of the resized image as usual. Their hosting was recently upgraded and switched to PHP 7.4 and I'm wondering if a they've removed a PHP package or changed a server config to cause this. Does anyone know if the image resizing functionality requires specific PHP modules I need to check for? I've checked the folder permissions on the server - this all looks fine. TIA, J

Also check the source server doesn't hasn't blocked image hotlinking or downloading of images without a referrer. I had an issue with an import script once along these lines.

Yes 100%. I built and run a client-specific CRM/membership system for an arts organisation using Processwire. It started out relatively simple and has grown, but allowed us to build exactly what was needed and cut-out the over-complication of the many off the shelf systems they had already tried. Without PW's baked-in features development of this system would have taken an immeasurable amount of time longer.

Hi @DV-JF - I'm pretty sure I do have both these enabled but I will check thanks. I have found that IP restriction works fine for my requirements though after all - turns out that my server was reporting an IPv6 IP and not the IPv4 I had set in the restrictions. ? So back up and running for now ?

I looked into this further. I tweaked the module to dump out the response from Google API and it confirms that indeed referrer restricted API keys won't work with the Geocode API. Array ( [error_message] => API keys with referer restrictions cannot be used with this API. [results] => Array ( ) [status] => REQUEST_DENIED )

I'm just using this module for the first time in a while and finding similar behaviour (Google Cloud has change a lot since I last used this module). I haven't tested the scenarios as thoroughly as @TheMick however I can confirm that everything works without the API key restriction, however restricting it by IP or Http referrer in GC dashboard generates a 'Error geocoding address' response and the lat/long fields don't populate.

@Robin S Thanks for this - really useful and puts my fears to rest. @gornycreative Thanks also for sharing info. I can't see I'll need anything like 50 of templates (famous last words ?) and TBH what I'm building is should have pretty low demands in terms of resources anyway - for the end user its more of a set-and-forget scenario. So demands should only increase with a significant number of users... but hey that's a good problem to have eh!

Thanks for the detailed response. This basically summarises exactly the choice in front of me... I'm pretty sure I can dramatically reduce the amount of code by using a new template for every view or configurable feature of my app and feeding it into my _main.php. But I'm not sure if creating loads of templates (I would estimate this will end up being around 10 to create the product MVP) is bad idea or particularly inefficient approach in terms of performance and database?

Hi all, Just embarking on a new web app project that I'm planning to use Markup Regions for. I've experimented with Markup regions before and am happy with the syntax and coding but wondering on the overall approach. The project will have a simple user dashboard with various typical web app views for account management, settings etc etc... I'm wondering am I better having one 'dashboard.php' template with PHP routing/conditions/includes to determine the content each page feeds into the _main.php file. Or is it better to have a seperate template for every page in my dashboard? I could end up with quite a lot of templates to realise my final functionality this way and pretty sure I've seen posts that PW is intended to have a vast number of templates. However routing all the views with new code could also get quite complex quite quickly too. Wondering what thoughts/experiences others have had - I hope this questions makes some sense!

Hi @Macrura thanks for this - module looks fantastic and not sure how I managed to pass it by until now! One quick question - can you export settings to other sites? One big advantage of coding modules is obviously the portability.