dragan

Did you use the value|title approach in your setup? Last section here: https://processwire.com/api/modules/select-options-fieldtype/#defining-options One workaround / solution would be to use value|title, and let the region be a search-filter in the frontend, not available for freetext search. My preferred setup for such things is to use page-reference fields instead of input field select options. And also, to only make text(area) fields searchable - category-type stuff (like offer_region) only queryable in the frontend via a filter (radio buttons, select, checkbox...). But I can understand that if you've already got a live site with lots of real data in your PW installation, it's not so easy to refactor everything without the potential danger of data-corruption.

In page-edit view: If I wanted to display the total count of selections, is there an in-built PW method for this? e.g. let's say the default view is collapsed for a page reference field. I see the label "Services" but would like to see "Services (3)". I would know that three items are selected without opening the inputfield. And ideally after every change, the number gets updated (without page-reload). Did someone once built something similar?

You should activate ACF + HTML Purifier.

OK, I think I got it solved: I was using this piece of code $form->remove($fieldset); I removed this line and everything is back to normal again.

I'm having the exact same problem now as Can posted - for the first time ever. I cloned a template last Friday, set up a few fieldsets, and now if I edit and save any page that uses my OLD template, the fields won't get saved. No matter if it's a text field, checkbox or page reference. I checked if fieldsets were in the wrong order - everything look OK. I get the usual yellow confirmation at the top: Session: Saved Page: /projekte/website-hans-muster-ag-standard-project-template/ and the URL looks OK too: URL: page/edit/?id=10202&s=1&c=0 No JS errors in the console. I've never seen anything so weird. Thank God this is happening on a dev environment, not live... I tried it with all 3 installed themes, and with both Chrome + Firefox. PW 3.0.108

In one of my templates, I have divided my fields into 5 fieldsets. The default tab now only appears when you create a new page. Once saved, you only see the custom 5 tabs. Now my problem is: When you open a page with such a template, it still jumps to the 1st tab (which is hidden by custom CSS). How can I achieve that it shows another tab? Would I have to write a hook? Some sort of redirect? e.g. I want to open the "Projekt" tab, so I don't get to see an empty page with just the save-button, when opening a page using that template.

@LMD Thanks for this post. I'll definitely keep this bookmarked.

oops, of course. Works like a charm now. . Thanks for the heads-up. Will keep it in mind.

$this->addHookBefore('InputfieldTextarea::render', function($event) { $field = $event->object; if($field->name == 'body_offer') { $del = ''; foreach($this->wire->pages->get(11229)->textblocks as $item) { $field->entityEncodeText = false; $body = str_replace(PHP_EOL, '', $item->body); $body = addslashes($body); $title = $item->title; $field->description .= $del . "<a href=\"#\" class=\"ckesnippet\" data-snippet=\"$body\">$title</a>"; $del = ' | '; } } $js = wire('config')->urls->templates . 'scripts/ckesnippets.js'; $event->return = str_replace("</html>", "\n<script type='text/javascript' src='$js'></script>\n</html>", $event->return); }); I'm trying to add custom text-blocks from repeater fields into CKEditor. I've stolen the whole idea (and code) from @bernhard Problem is: The links are actually being rendered, but the Javascript is not loaded, i.e. the $event->return line doesn't seem to work. If I inspect the HTML, my additional script-tag is nowhere to be seen. I don't get any errors either. Running latest PW dev + PHP 7.1.19.

Does each company edit their products themselves? i.e. does each company have an admin-access? That would make the whole process / setup a bit more complicated. You would have to make sure that each company-admin only has the necessary rights to edit their own colours. It would all still be doable with PW - it would just need a bit more planning, and thinking ahead of the whole structure/architecture.

You also have to edit your site/config.php, mainly the database credentials and perhaps the allowed $config->httpHosts array. You can temporarily set $config->debug to true, to see error messages, should they occur.

What's the reason for this strange sounding setup? So you want users to be able to create and edit pages, but not via the default template, and without the necessary rights? Why? Are you trying to create some sort of review workflow, i.e. the admin has to approve the classified first, and only he can then publish it? If that's the idea, you could simply work with page status: Only the admin can publish a new classified. (kinda like user-comments have to be reviewed and approved by someone, before it's published)

Why don't you use a pagefield? It's as simple as using $page->fieldname (inside the template). In _init.php, you would use $pages->get(123)->fieldname, where 123 is the id of the page your field lives in. If you have multiple instead of single values, you would have to loop through them, but that's easy as well.

OMG, not again... https://www.pilcro.com/blog/headless-cms By that definition, PW is most definitely a HCMS...

?field=yourtab It's probably too late right now... approaching midnight here, but I am not sure where or how to use this. Do you have a simple example? You add that to your page-edit link as a param? If so, that's not an option, since I don't want to write a module, but still be in the "default" page-edit area. I don't want to mimick or refactor the whole page-editing somewhere else.

I know, but if you leave the admin, logout or go somewhere else, e.g. edit another page or whatever, you'll find that you get the 1st tab again. The general idea behind this question is: A relatively big page (lots of fields, lots of "show only if" conditions) should be split up into several "process steps" - hence the tabs approach. The user is supposed to be "guided" in the page-editing process that if he only has completed tab 1-3, the next time the page-edit screen is opened, tab 4 is shown. Think of multi-step forms, a shop checkout process or similar.

Is it possible to open a specific tab, when in page-edit mode? Let's say I have 5 tabs (more than just the default "content" tab - 4 more created with field-groups), and the user is in tab 3. How can I possibly manage to set tab 3 again to active/selected when the same user wants to edit the same page after x days? Are there any in-built methods I could use? And which hook(s) would be necessary?

https://processwire.com/api/ref/wire-mail/ Use $m->bodyHTML('<html><body><h1>Message Body</h1></body></html>'); in addition to $m->body();

If you reduce the image max-width (or the div above with no class) to approx. 66%, it looks OK. But ONLY in IE ? Maybe use MS vendor prefixes for IE, or the old if-IE conditional tags

Awesome. I also like @theo's "preview / page-grid" module a lot. I realize they don't do the same stuff, but just imagine if you had both functionalities available!

What error exactly? You should post the error message here as well.

Interesting! So you're saying that's your own business venture, not working for a client-project? Good luck with that project. I can surely see potential for such a verification process. Gonna read more about it when I have more time. I tried to verify one of my sites and came across a bug(?). When I entered my site URL, there was an error message showing up: Wrong URL. (white text on red background, beneath the input field). The URL is most definitely correct though. What's strange: I could actually proceed to the last screen, where I have to enter a password etc.

I don't know, but it could be this issue: https://github.com/processwire/processwire-issues/issues/627

I never worked with Drupal, but reading this about Drupal Views - I have to say there's nothing there feature-wise that you couldn't do with PW (even without extra modules). Unless I'm missing something... I just read the overview page. PW's selector and Page Arrays are very powerful and flexible. When you started out with PW, didn't you see the selector docs?

I see where you're coming from, but I would kindly disagree. PW will never really cater to the "click-and-install-my-entire-website-and-then-you-will-have-your-latte-macchiato-ready-for-you" crowd. wix.com and whathaveyou will do that for you, cheaper and faster. Where PW really shines, is: Creating something that lives on the web, and doesn't make any assumptions how you're going to (re-) use that data in your frontend. There are so many trendy buzzwords, that it's hard to keep track of... PW is (e.g.) perfectly suitable as a "Headless CMS", or whatever the mot du jour is... For such scenarios, "modern website presets" just get in the way.