elabx

I don't think there is a "best practice" written down somewhere for this sort of scenario. I agree it can be confusing to figure out the "right solution" when there would seem to be so manyw ays to achieve the same. If all the values from the identifier are okay with being a text type value, I would go with a Table field with two columns, a Page Reference that fills its options with the "catalogue" of "possible IDs" and a text field that acts as the field for the actual value, this way you can have whatever fields you want on each organization, and you can do stuff like: $pages_with_purls_identified_orgs = $pages->find('template=organization, ids_table.id_type.name=purls'); This also guarantees you can also add new identifiers in the future very easily and consistently. You could do almost exactly the same with repeaters. Why table and not repeater? I just prefer the interface of the table field, I think it's less clunky visually when few fields are involved and has a more snappy feel. If each identifier would need more data added, I'd go for a repeater, but since it seems it's just an ID name and the actual value, table field seems enough. Repeaters would also have the "overhead" of loading an extra page on memory per repeater, since each repeater item is a processwire page. Although another scneario, what if the value of each identifier is a different type, then the table field would not work as nicely. Say you need DOI to be alphanumeric and ORCids to be integers, maybe for this case a repeater could work, with the same catalogue of identifiers, except that you create two additional fields (one text type, one integer type) and show them conditionally depending on the value of the page reference field where the type of identifier is selected. Please take this idea with a grain of salt, just something I came up with right now. It might be a hassle to manage the relationship of "identifier - type of value" on the actual code, or it might be worth the trouble, or there might be a better solution out there ?

@benbyf I'm still using it without issues! And even use it with @bernhard's RockMigrations . I think there is an issue with the composer install related to composer 2, but you should be able to install it like a normal module. EDIT: @benbyf dude I completely tripped and was thinking I was in the old Migrations module thread lol Nonetheless, I have also used this project a lot and noticed it breaks with most recent php version, I think 8+

Could you do a search through your codebase to find if somewhere you might be assigning that property to the page (a typo)?? At east it happens to me sometimes that I swap a variable's words like that lol Came for the title, stayed for the issue ? Like, wow what's FieldtypePhantom

That was one of the first games I had on PC!! I was like 10 or something, I couldn't believe there was such a funny game haha, it really opened my eyes to what could exist as a videogame. Now I'm thirsty for some table melting quality grog.

Is the repeater set in the projects template? Maybe a screenshot of your template/repeater field config could help!

They are, you need to configure that inside the repeater field, on the Details tab where you add the actual fields for the repeater, click on the field's label/name and it will popup a configuration screen that will be set the configuration in the context of the repeater field. (in case you use the fields in other places, for example)

Wouldn't this be the concept of a template, that has the 15+ fields you need. So on your page tree you could end up with something looking like this: - Cards (a page with a template called cards-display-page, without any other field aside from title) -- Card 1 ( a page with a template called card, with the 10+,15+ fields you need) -- Card 2 (another page of type card, ready to be filled) Since you seem to be new to ProcessWire (at least from what I perceive on your posts!), maybe you are not familiar with the idea that a Page can also be just a sort of "data bucket", it doesn't really have to render the page itself. I see that you have solved this issue of your cards with a Repeater, though just wanted to let you know you could potentially do this, and actually behind the curtains, Repeater items are actually regular Page objects! I have used Perch in the past to build a couple sites and I do remember it was very practical to define fields inside the templates.

Hi @spercy16! Are you super sure tall_card is the name of your repeater field? It seems to be a non existent object.

That's a very good question haha, it just happened to me just today when moving a live site to local development for some upgrades and found the recommendation around the forum, I didn't dig much deeper into the exact issue with the fingerprint and the change of environment. Though I can tell you I noticed that had to be related to the fingerprint because the session log shows a message about it. You should still be able to something under /site/assets/log/session.txt. I can also tell you that those lines are not originally on the file because the site/config.php file is sort of an "override" to the more complete wire/config.php. So in that link I pasted you can see the whole configuration, and on the site/config.php file you specify exact details of your installation. I don't think the order is really relevant on this files as the values defined are used further in the actual execution of the ProcessWire scripts.

Can you try on site/config.php: $config->sessionFingerprint = false; $config->sessionChallenge = false;

I remember this topic being one of those moments of "enlightenment" when learning processwire haha.

Move the page in the tree to be sibling of Pages, like you would with a regular page.

Related: https://github.com/processwire/processwire-issues/issues/550

Try: $page->parent->get('menutext|title');

Very interesting thread! I've had a couple people pretty amazed too by the volume PW can handle but this case is really interesting!

Maybe some sort of server cache layer? Are you working local or on a server? Last but not least, the cache on your developer tools.

I think this can actually be a good starting point overall. First, install a ProcessWire blank profile. If you do the file rename services.html -> site/templates/services.php, later you'll have to actually create the Template in ProcessWire, which automagically maps by name to a file by default. Say, template "services", matches to file "services.php". Actually if you add "services.php" to the site/templates folder and in the processwire interface try to create a new template, ProcessWire will suggest to create templates according to the existing files. After you do do this, you can go and recreate the pages in the page tree (assigning the right templates, to the right pages) you could end up with a "static" copy of your website. After this, you can think of adding the fields to the templates! This part involves a bit more, like installing the language modules, setting up the language fields, etc. But I could save that for later.

wire()->addHookAfter('FieldtypeOptions::markupValue', function($e){ $page = $e->arguments(0); $e->return = $page->select_options_field->id; });

Assuming that code is within a string, try: echo "<img src='{$repeater->field->url}'>";

It happens to me on Runcloud which I think has basically the same scheme as Serverpilot.

I've done this exact same path and it works really well with the bare minimum, check that doc page @szabesz sent. Stripe Checkout simplifies things a lot. FormBuilder seems to do this "plug and play" but I have honestly not tried it. The implementation of the checkout process is really minimal to get to the Checkout page if you want to remove FormBuilder from the equation, it ends up as very little code.

Like @bernhard mentions I think Snipcart is a great option, I also feel depending on how simple the selling part is, you could use FormBuilder + Stripe.

https://github.com/blue-tomato/TemplateEngineSmarty Check the last part of the docs, Extending Smarty, it has an example on how to register object/functions. If I understand correctly functions.php, the kind of functionality that it enables would translate on the hook system of ProcessWire. https://processwire.com/docs/modules/hooks/

Nice work! Just heads up you left ProCache debug on!

Is the profile going to be saved "outside" of the modal? And then you'll click Save on the profile page? Does the modal have some documentation? It probably has a save/close callback so you can then get the value of the modal form field and copy it to your main profile form. It seems a little strange to open up a modal to edit a text field, why not right there on the input? Obviously I might lack context.