Leaderboard

Hi Iraklis, and welcome to the forums! I can't entirely figure out what's going on from your description, but here's some information that may give you a foothold. PW has two types of field ("fieldtypes") for selection options, and it sounds as if you may be dealing with the second of these: Select Options, where the options available are defined on the Details tab of the field definition. Page Reference, where each option is set up as a page, and you select the page. The page could be a page that appears on the site, but it could be something as simple as a name (e.g. the name of a country) used only as an option for selection (and doesn't appear as a page on the site). This seems a little odd at first, but it's a powerful and flexible way of doing things! You'd find the pages somewhere in the page tree, either under Admin or somewhere else - e.g. you might have Value Lists > Countries > Afghanistan etc. To find out which type of field you're dealing with: Setup > Fields > Your field > Basics tab > Type. To find out what template a page is using: Your page > Edit > Settings > Template. You'll find template files in Site > Templates. Let us know if you need further help.

Do you mind posting your menu-builder code and the things related to it. Maybe there is something off of some kind. Another thought here... did the database crash in the past or something? I can't remember having that issue in any of my sites or projects so far.

Found these two links with more details about Page::statusCorrupted: https://github.com/processwire/processwire-issues/issues/909 Even though I read both parts I'm not really sure what to do next. I'd probably try saving that page again via API with output formatting off or maybe even just create a new page and move all content over to that new one.

Glad you got it sorted :-). I have never used srcset myself (I think it is a third-party module?) but this should work since media is a Pageimage object in this case. This is used in the ProcessWire sense of image variations as briefly explained here. Whilst you can certainly utilise variations for responsive designs, they are not limited to that use.

So... first thought was: no mod_rewrite or a missing .htaccess file. But as you just uploaded everthing the .htaccess can't be there as the installer puts it in place while you install everything. As you weren't redirected to the installer the missing mod_rewrite support persists but... that shouldn't be the case on any modern hosting. The question now is... what kind of setup are you using: Shared hosting, vServer, Laragon, XAMP, MAMP, or ... ? Just in case: double check mod_rewrite support and as the file permissions. Maybe that's the problem. Just a guess. https://processwire.com/docs/security/file-permissions/ Can you tell us a bit more about the PW version, PHP version, MySQL/MariaDB version, etc.?

Not that I know of; But this forum has heaps of code examples. Writing an export script would assume a decent knowledge of the PW API, and a certain basic level of PHP. If you are willing to invest some money, then you could simply purchase ListerPro, and then use the ListerPro Page Action: Export pages to CSV file "This action enables you to export all pages matching your ListerPro query to a CSV/spreadsheet compatible file."

v0.0.64 adds a new method $rm->createViewFile('yourtemplate'); that creates a file /site/templates/yourtemplate.php That might sound like overkill, but when used with class constant and OOP that makes it clear and easy: <?php namespace RockTeam; use ProcessWire\Page; use ProcessWire\RockMigrations; use ProcessWire\RockTeam; class TeamPage extends Page { const prefix = RockTeam::prefix; const tpl = self::prefix."teampage"; const tags = RockTeam::tags; /** * Triggered in RockTeam::migrate() */ public function migrate(RockMigrations $rm) { $rm->migrate([ 'templates' => [ self::tpl => [ 'tags' => self::tags, 'icon' => 'users', 'fields' => ['title'], ], ], ]); $rm->createViewFile(self::tpl); } }

Correct, ProFields Page Table is the one that comes for free with PW. Profields Table is not the same thing.

@ErikMH Great question. I think elabx has pretty much covered the repeater and table options - both of which work really well. So I'll skip these and just mention a couple of other possibilities, both of which I've used in various sites (in addition to the table and repeater fields) Child pages Repeater Matrix Child Pages It might be possible, depending on you application, just to use child pages to house your set of related items. This won't be the case if you intend using the page url structure for something specific on your site, but if you aren't then you can set up a template per type (one each for purls/orcids etc) and use the template family relationship to restrict the parent-child relationship as needed. Thereafter you would just add child pages to each of your organisations. I use this method in my little invoicing system for the payment methods accepted by each of my personas: Output in the API is simple, just iterate over each of your page's children to produce your output: Repeater Matrix If you have access to the ProFields package, this is probably slightly easier than using regular repeaters as you get to specify the allowed "types" of the items when constructing the field. I also find the interface more intuitive than normal repeaters and the rendering is particularly nice as it allows each item's code to be in its own PHP file. In the case you mentioned (Organisation with 0-n links or IDs of vaious types) I would probably go with a repeater matrix or the Table field as mentioned by 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 ?

For this to work, one needs to modify PW's root .htaccess at "# 4. Protect from XSS with Apache headers" of the "loaded site", something like: <IfModule mod_headers.c> # prevent site from being loaded in an iframe on another site # you will need to remove this one if you want to allow external iframes # Header always append X-Frame-Options SAMEORIGIN # Lets the listed domains load content into an iFrame Header always append Content-Security-Policy "frame-ancestors 'self' example.com example.test www.anotherexample.com;" also, it is probably a good idea to turn the iframe into a responsive container: https://github.com/davidjbradshaw/iframe-resizer

The usual way that I would do it is to create a service URL* on the 2nd website, which returns JSON to the ajax request, if you're going to load the comment markup and form via ajax. Alternately you could use an iframe, so the 2nd website would have an output template to render the comments thread and form; this could be a single template/page with get params; I don't see any benefit or reason to use multi-site / multi-instance (but maybe i'm missing something), unless it makes managing comments for an article easier; but you could also create a field in the comments site that pulls in the title or other info from the main install, using a service page on the main install, returning JSON response; In terms of the service "page" or URL - there are some new api features that will allow you to have a service URL without having to actually create a page as an endpoint. https://processwire.com/blog/posts/pw-3.0.173/

You can use multiple instances of processwire and include one in another. $pwComments = new ProcessWire($config->paths->root . 'site-comments'); $home = $pages->get(1); $homeOfComments = $pwComments->pages->get(1); https://processwire.com/docs/more/multi-site-support/ use Option #1 https://processwire.com/blog/posts/multi-instance-pw3/#using-multi-instance-in-pw3 This is also possible under a single domain if you do not need a frontend at one of the two installations and use different names for your /admin/ pages and session cookies. Under special circumstances you can also access the current user of one instance within the other. Look here: https://github.com/processwire/processwire-issues/issues/1294#issuecomment-759351593

Hello again, a very nice guy sent me a pm with some suggestions and of of them worked: And it wasn`t activated but needed... So it works fine now! Merci encore pour tout, C.! Kind regards Christian