Leaderboard

To be fair I believe we're on the same page here, except for one detail: those modules — Seo Maestro and Markup Metadata — are actually two very different solutions. In fact what you're describing is exactly why we use Markup Metadata by default in our projects: there's no GUI, and a big part of the markup is based on globally defined values or values from (pre-existing) page fields. It's just a markup module for handling the repetitive task of rendering a standard set of metadata elements, correctly and consistently, from project to project. That being said, in my experience some people prefer a more complex approach, either because they actually need it or because they think they do — and if a client was specifically requesting feature set similar to that of Yoast, a solution such as Seo Maestro might be just what you need to convince them that they don't need to go with WordPress just for that ?

Fantastic, thanks to you both. This community is excellent. I will look at those plugins but like @MortizLost I favour the KISS approach. And the important point is external tools can not only be more specialist you are always evaluating the final complete HTML document as opposed to whatever the CMS can do. I find in PW, for example, I will have blocks of includes that pull in a list of content from elsewhere in the site tree (such as a list of team members or featured case studies) but anything Yoast-type would have no way of knowing this as the template decides it. Yes, it could pull the HTML via AJAX based on the page's path but this is overkill, in my opinion. Also, these tools make help you pick up on things you've missed but they can't evaluate anything within the context of a wider SEO strategy.

Just to go against the grain a bit: Those modules are way, way overkill for 99% of sites. Just looking at the screenshot in the Seo Maestro thread, all those options would confuse most of my clients. Who really wants or needs to manually edit the change frequency of a single page? Some of those options should also be generated automatically (Locale, based on the current language) or set globally (Site Name, for example). I get that you can control which fields to show and that it's kind of a framework which you can use for all kinds of sites. But in my experience, showing five screens of SEO settings on every page is the best way to get clients/editors to be scared of them and never use them. Three fields - title, description, preview image - are all you need most of the time. KISS. I would use external tools for this. There are many tools that are much better at this stuff than Yoast, and they look at the page as a whole, not just the body content. For example, at work we have at some points used the following tools among others, in no particular order: Ryte, Seobility, Semrush, Sistrix. And many more ...

Same. I also tend to bundle these with fields for open graph metadata, option to override page title separately, and whatnot. You might want to check out module solutions if you haven't yet. Seo Maestro is a neat one, and MarkupMetadata is what we use for our web projects (though latter one doesn't provide a GUI for content editors, it's just for generating proper markup). My experience is similar: the content analyzing features of Yoast have never been particularly useful for me, in part because I've mostly worked on non-English sites where they don't seem to work so well. Also these reports seem to — at best — provide a rough estimate of how good your content might be, and (in my opinion) there are better tools for that. If your clients are often interested in doing "hardcore SEO", I'd definitely dig into external tools and see if there are some that you can recommend instead. Yoast has some nice features for working around WP's shortcomings, and I've found their "helper" tools (such as breadcrumb creation) pretty handy in the past. ProcessWire, on the other hand, makes things like breadcrumbs and canonical links trivial, and the structure is often so straightforward that you don't need to do a whole lot to make your site "SEO friendly". One thing to note is that Yoast actually does handle "modular pages" relatively well. Last I checked it required a separate plugin and only worked if your content was all visible in the editor, though. My understanding is that it just mashes it all together and then does its magic. Crude perhaps, but in many (if not most) cases this provides decent results ?

Should be easy enough with a combination of https://github.com/somatonic/Multisite and http://modules.processwire.com/modules/admin-restrict-branch/

https://processwire.com/api/ref/wire-array/import/ That's correct, the sort order of a page's children is relative to that level of hierarchy, not global. So by using pages->find with the sorting order you get weird results. I don't think there is a way to get a hierarchically ordered result in one query. Do you want your page array to be ordered depth-first (first page -> children of first page -> second page -> children of second page -> ...) or depth-first (first page -> second page -> ... -> children of first page -> children of second page -> ...)? I assume you just need your $articles variable to be a flat array of all pages in their page tree order, correct? I don't think it can be done in one query, but you can use WireArray::add and WireArray::import to create your flat array of pages. For depth-first order: $articles = new \ProcessWire\PageArray(); foreach ($page->children('template=event, hide_in_programm=0') as $article) { $articles->add($article); $children = $article->children('template=event, hide_in_programm=0'); if ($children->count()) { $articles->import($children); } } For breadth-first order: $articles = new \ProcessWire\PageArray(); $parents = $page->children('template=event, hide_in_programm=0'); $articles->import($parents); foreach ($parents as $article) { $children = $article->children('template=event, hide_in_programm=0'); if ($children->count()) { $articles->import($children); } }

BTW, the new migrate-method together with Tracy Console is a game changer ??

Google Tag Manager is useful to track form events. It is how I have tracked visitors use of forms earlier. In addition to the method @MoritzLost suggest, there are ways to track this in the Google Tag Manager admin based on IDs and classes.

What do you mean by form output? Generelly, forms are used for input ? The first step is to determine which interactions you want to track. For example, you could track an event: ... whenever a form is successfully submitted. ... whenever a form is partially filled but then abandoned. ... each time somebody fills out an individual field (will result in many events). ... whenever somebody finishes an individual step of a multi-step form. Beyond that, you first need to determine what your client wants to know, in terms of specific metrics, interactions etc. Most of those you can do with simple event handlers reacting to form changes, inputs and button clicks. // find all formbuilder forms on the page const FormBuilderForms = Array.from(document.querySelectorAll('form.FormBuilder')); // track the submit button FormBuilderForms.forEach(form => form.addEventListener('submit', e => { // this assumes you're using gtag.js with transport mechanism 'beacon' gtag('event', 'form_submitted', {/** add additional information based on the form data */}); }); A bit more tricky is tracking submissions only after they've been validated server-side, since you can't catch that with JavaScript. However, after submitting a form you will usually show a success message or redirect to a dedicated thank you page, so you can just track those: // FormBuilder uses this ID for the submission message const FormBuilderSuccess = document.getElementById('FormBuilderSubmitted'); if (null !== FormBuilderSuccess) { gtag('event', 'form_submission_result', {/** track the name + result of this submission */}); } Does that answer your question? It's just a matter of determining what you want to track, and then adding appropriate event handlers with JavaScript.

Does anybody else feel like the login screen could use a revamp? While it might not be the most important thing in the world, first impressions count. On large(r) screens the login form seems to get lost in the upper third. The rest of the admin looks a lot cleaner and more deliberate. A few tweaks would go a long way in making the login screen work on all device sizes. Those are two custom styles I've been adding to my sites lately, one PW-branded and one not. No markup changes needed, just CSS. This second one borrows heavily from Twill's login screen. The floating environment label has turned out to be really useful to see at a glance if one is editing on staging or live. Not sure if there's a way to make this 100% core compatible.

I don't think it's possible to use regex in config.allowedContent, but this seems to do the job: CKEDITOR.on('instanceReady', function(event) { var rules = { elements: { a: function(element) { // If a link href starts with 'javascript:'... if(element.attributes.href.substring(0, 11).toLowerCase() === 'javascript:') { // ...then the href is invalid so remove the link delete element.name; } } } }; event.editor.dataProcessor.htmlFilter.addRules(rules); event.editor.dataProcessor.dataFilter.addRules(rules); });

I marked your topic (title) as solved ?.

That's where a proper IDE should kick in, to do its stuff (auto-suggest/auto-complete etc.). Mere text-editors can only do so much... With PW, that didn't really work so well for a long time. But if you enable the Functions API, and use page() instead of $page in your code, you'll get the hints in your working environment. /** * Allow core API variables to also be accessed as functions? * * Recommended. This enables API varibles like $pages to also be accessed as pages(), * as an example. And so on for most other core variables. * * Benefits are better type hinting, always in scope, and potentially shorter API calls. * See the file /wire/core/FunctionsAPI.php for details on these functions. * * @var bool * */ $config->useFunctionsAPI = true;

It's been 2 years @kongondo Is there any updates on this???

Hello MrSnoozles, in Processwire template files are not actually templates and You can actually use them as controllers (see the "delayed approach" in pw tutorials). In template files You can manage the request ($input), build forms (InputfieldForm module instances) and assign variables which are later used in the included view file(s). (btw, I use the ".phtml" extension for my views/partials to distinguish them from template/controller files ".php"). If you ever worked with Silverstripe you can actually think of template files code as Silverstripe's Page_Controller classes ' method code. You can leverage pw's urlSegment feature to add sub-routes for the current page/template. If you have a contact-page template (/contact-us/) You can use a "submit" segment ($input->urlSegment(1)) and use "/contact-us/submit" as the form action, the same way You can add any route segment in a Silverstripe (Page_)Controller class. I don't find it useful to add code used only by the "contact-page" template in a global function inside (_func.php). As in Silverstripe cmf the segment approach has the advantage that it continues to work even if you change the url (name) of the page using that template. Think of template files as controllers: while in other frameworks you have to assign controllers to routes, in PW a route (Page path/url) is automatically linked to a peculiar controller (template) by the fact that the Page with that route is using that template. kind regards, maks feltrin