Jan Romero

I don’t think that’s a bad thing per se, but I agree the big PHPStorm background could probably be replaced by just the slideshow of PW admin screenshots that currently plays awkwardly on top of it. Perhaps with one or two code screenshots intermixed. In general though, maybe I’m just old, but the site doesn’t look outdated to me at all? At least the frontpage looks as fresh as ever to me. Welcoming, professional, you name it. Certainly no worse than the examples mentioned? Wordpress has a trendy serif typeface which I get is part of their printing press shtick, but I honestly find kind of offputting for what it is (also the footer is grade A pure unadulturated organic cringe and all their images are blocked by Firefox’s default tracking protection). Structurally I think the ProcessWire site could use some improving, especially these “hub” pages like https://processwire.com/docs/, especially especially if they link to the next identical looking hub page (eg. https://processwire.com/docs/start/). Someone mentioned earlier that it’s a shame a lot of great nuggets and frankly vital info can practically only be found in blog posts. I know I’ve searched for specific blog entries I knew existed plenty of times, wondering how someone who hasn’t kept up with PW for over a decade would find out about stuff like custom user parents, for example. It would be great to have a more official tutorial section for these things which the blog posts would then link to. The current tutorial section only has 10 tuts, most of which, including the "More Tutorials" link, are secretly external.

Sorry, I told you I was just guessing 😅 It should work using the updated code above. Apparently "owner" needs to be prefixed by the name of the repeater field. This time I have tested it.

Would this help? https://processwire.com/blog/posts/processwire-3.0.95-core-updates/ I guess it would be something like this, but I’m on mobile, so untested: $pages->find("template=repeater_leaderboardCategories, carsOrCarClasses=5941, include=all, leaderboardCategories.owner.id=6057");

It’s not a folder, but the URL http://localhost/processwire should be accessible and show a login form. ProcessWire dynamically handles such URLs using, among other things, the .htaccess rewrite* directives. I believe you’re asked to optionally rename the admin URL during the installation. Some people like to do so to obscure the login page from attackers. If you have entered a custom admin URL and forgotten it, you can check the database table “pages”. It should be ID 2. But maybe just try reinstalling from htdocs. It shouldn’t give you any htaccess problems IIRC. I spun up a PW installation on XAMPP on Windows only a couple weeks ago and I don’t recall having to change anything apart from enabling some optional php.ini features ?

Yes, if you only plan to access PW on http://localhost I would just do that. If you want it to accessible at http://localhost/processwire-master I believe you need to add RewriteBase /processwire-master/ to section 8A in the .htaccess file. The processwire-master directory is only put there by GitHub, it doesn’t really “belong” to ProcessWire per se.

Welcome to the forums! Are the site and wire directories directly inside htdocs, or within a subdirectory? You may need to check section 8A in your .htaccess.

Obviously I haven’t used this myself I feel like there is some confusion in this thread regarding the storage model? My understanding is that the data in the database looks the same as any other field, ie. each field has its own table with subfields being individual columns. AFAIK that’s how Profields Combo works, which this has been compared to. That would alleviate @poljpocket’s concern about selectors. One would simply use the usual dot syntax. As with all dynamic db schemas the issue then becomes migrating data inbetween schema changes. „Stock“ ProcessWire helps you here by only allowing safe changes through the UI and/or showing warnings if data loss may occur. Such safeguards are presumably absent here, but I guess you’re supposed to know what you’re doing when dealing with code anyway.

Neato ? You may want to turn this into a FieldtypeMulti to let PW take care of some of the database paperwork and get selector support for free.

I don’t have access to those threads, but I have bought ProFields several times and one Table-adjacent thing I’d enjoy would be docs/improvements for paginated FieldtypeMultis. I know there is some support for this in the core but I’m not sure it’s meant as a public API. AFAIK it’s currently only used by Profields Table. In particular I’m not a fan of it using the global pagination by default. I seem to remember some ugly hacks to be required to get independent pagination per field.

Full ack. I’ve long appreciated and admired the tasteful restraint with which Ryan has been steering the project all these years, but even so, PW has accumulated some features/concepts that could still use some love. The custom page classes being one hotly discussed example recently. A lot of the suggestions here would make for great third-party modules. If we want more module developers and more core contributors, an official test suite may be helpful, as would better docs and more developer relations like this (also possibly someone deranged spamming memes on twitter every 10 minutes). Obviously I say this with two hearts beating in my chest, because we all know the failure modes of playing these engagement-chasing games and of large communities in general. Regarding database abstraction, to be a little flippant, if I wanted to pay for or manage that kind of hosting, I would be building on ASP.Net Core and not use an insane language where 0 == null. I’m here because PW runs on little shared hosting plans for less than a cappuccino a month, I think a lot of us are, and as much as that sort of thing is derided and reported dead, it’s an okay niche to serve. (No hate here, I love Carson Gross, .Net, PHP and everything) It’s an absolute travesty that this sort of thing isn’t a browser feature. At least give us date ranges already.

This seems to work because PW contains this “abnormal request” fallback, where it looks at $_SERVER['REQUEST_URI'] directly if the ”it“ query parameter is missing: https://github.com/processwire/processwire/blob/e508cfa2a74971490d6045bd5eb6f2a198d37037/wire/core/PagesRequest.php#L537 It involves some additional processing, removing the query string and PW’s subdirectory.

Omg I just got these errors last night, unrelated to the module. Guess my hoster updated Apache. Thank you for this thread ? I don’t understand the security issue and can’t seem to find many details on it, but must be pretty bad for them to break such a widespread use case…

I think existing pages always have precedence over path hooks, so if a page called “/folder/4545” actually exists, no path hooks will run for such a request. But in your example, the page is actually called “/folder/4545-foo-bar”, so a path hook like this would trigger: $this->wire()->addHook('(/.*)/([0-9]+)/?', function($event) { $page = $event->pages->findOne([ 'parent' => $event->arguments(1), 'my_id_field' => $event->arguments(2) ]); if($page->viewable()) $this->wire()->session->redirect($page->url); }); This should find any path whose last segment is an integer, try to find the page with that integer among the children of the preceding path, and redirect to it. Normally I would test this before posting, but I’m not on a suitable machine…

I could have sworn there was a $config->advanced option in template settings to disable this, but apparently there is only one to prevent a page from being moved. Of course, you might want to do that, too, if you need stable urls. Also note Bernhard’s hook only hides the field from the edit form, but it could still be changed through code or even (I believe) with simple browser dev tools trickery on the part of an editor. To prevent it even through the API you could probably hook into Pages::savePageOrFieldReady: https://processwire.com/api/ref/pages/save-page-or-field-ready/

You may want to use path hooks for this: https://processwire.com/blog/posts/pw-3.0.173/#introducing-url-path-hooks You can also hook into 404, but I don’t have a snippet handy right now. I’ll post one if no one beats me to it, but I think path hooks are probably the best way to do what you describe. Another option would be URL segments. You could define a regex to only allow a single integer URL segment.

Agreed. FWIW, this is how you might do the same thing for Field configs. For example, to have users enter CSV formatted data but store it as JSON, so it’ll automatically be available in a structured form: public function ___getConfigInputfields(Field $field) { $inputfields = parent::___getConfigInputfields($field); $myTabularData = $field->get('myTabularData') ?? []; $myTabularDataCSV = implode("\n", array_map(fn($r) => "{$r['surname']}, {$r['givenname']}, {$r['shoesize']}", $myTabularData)); /** @var InputfieldTextarea $f */ $f = $this->wire()->modules->get('InputfieldTextarea'); $f->attr('name', 'myTabularData'); $f->label = $this->_('Important config data'); $f->description = $this->_('Enter some important data in CSV form with the following column order: Surname, Given Name, Shoesize'); $f->attr('value', $myTabularDataCSV); $inputfields->add($f); $this->addHookAfter('Fields::saveReady', null, function($event) use ($field) { if ($event->arguments(0) !== $field) return; $csv = trim($field->myTabularData); if (!$csv) { $field->myTabularData = []; return; } $myTabularData = []; foreach (explode("\n", $csv) as $r) { $arr = explode(',', $r, 3); $myTabularData[] = [ 'surname' => sanitizer()->text($arr[0] ?? '—'), 'givenname' => sanitizer()->text($arr[1] ?? '—'), 'shoesize' => (int)($arr[2] ?? 0), ]; } $field->myTabularData = $myTabularData; }); return $inputfields; } So… yikes. Is there a better way? Of course it would be optimal to just have a bespoke structured Inputfield.

PageTable is free because a gracious Finnish company sponsored it ? It’s just called "ProFields PageTable" for historical reasons. There are also modules like PageTableNext that extend it futher. I would imagine you can switch between Page Reference and PageTable pretty easily. In the database, they look just the same: two IDs and a sort number.

I think you should be able to just drop your "site" directory right into the new machine’s PW installation, replace the database, adjust /site/config.php accordingly, and it just might work. Unless your production system depends on PW core modifications, in which case it would be imperative to find out what those are. But I’d see if it works before looking into that.

Here’s a PR that would guarantee pages to be newly created from the create textarea (if so configured): https://github.com/processwire/processwire/pull/298

Yes, I see, sorry ? It should only update pages that are new or don’t have a number yet. You can remove the condition “|| $floor->floor_number <= 0” to only handle new pages. I’m still not sure what you need the numbers for. Will they be read-only? My hook will generate them by counting all items in the page reference field, but there is no guarantee someone isn’t going to change a number later and end up with duplicates even within the same page reference field. ProcessWire keeps its own number in the database to sort the selected pages. In the database it looks like this (using PhpMyAdmin): This sort field has the advantage that there should never be any duplicates. However, when users manually sort the pages, they will of course change accordingly, so they’re not tied to their page. Your main problem will still be that InputfieldPage does not just create pages as it explicitly says, but will choose existing pages if their title matches an entered line. In fact I haven’t found any indication for this behaviour anywhere but in the code itself. It’s clearly an intentional feature, but it feels like a bug when the inputfield itself only says “create new” and “they will be created”… You may be able to suppress this behavious with a hook but it’ll be ugly. Have you considered some of the more powerful modules like PageTable?

Have you tried migrating to the Ubuntu machine and upgrading ProcessWire there? Seems like you could skip all of this hassle with the old server? Obviously keep the old server running until everything works on the new one.

Nice first post, welcome!

Is there a specific reason you need to use this page-tree structure? It seems to me that one particular floor can only ever belong to one particular house. You could better enforce this constraint by having the floors be children of their houses or by having a single-page-reference field in the floors referencing their house. I would strongly prefer the first option, but it would change your URLs. Reasons you should change your structure to floors being children of their houses: It correctly models the 1:n relationship. Vitally, it doesn’t allow one floor to belong to multiple houses! You may not even need the custom floor number field because you can just use “sort” (sort starts at 0, so +1 accordingly). Adding pages from a separate parent through a Page Reference Field is weird and dangerous for your use case. For example, if you enter “Ground Floor” and a page called “Ground Floor” already exists (seems likely), it will silently use the existing page and not create a new one. Your URLs will be nicer in every way. Your current setup will have to create unique names for every ground floor, so you’ll eventually have /floors/ground-floor-27/ as opposed to /city-hall/ground-floor/. If you really like the /floor/ground-floor/ URLs, you can use path hook trickery to fake them. This is much less of a hassle than your approach. Here’s a hook you could use to generate numbers for pages added through Page Reference Field, but I’m telling you right now: don’t do this! $this->addHookAfter("InputfieldPage::processInputAddPages", function(HookEvent $event) { $inputfield = $event->object; $floors = $inputfield->value; $c = 0; foreach ($floors as $floor) { $c++; if ($floor->_added === true || $floor->floor_number <= 0) $floor->setAndSave('floor_number', $c, [ 'quiet' => true ]); } }); These are just my 2 cents without knowing all considerations of your project, so I may be completely off. There may also be better and more robust ways to achieve what you want than this little hook

With all due respect, disparaging PW over this is entirely uncalled for. It’s not a ProcessWire concern. Whether it’s links or redirects, your issue lies in interfacing with the browser. ProcessWire’s session()->redirect() is just a thin abstraction over HTTP/1.1 301 moved permanently Location: http://example.com If a browser doesn’t want your site to open a new tab, it’s not going to open a new tab. I’m sure you’ve seen sites of questionable repute apply some trick or other to open pop-ups, pop-unders and whatever else, and you can use ProcessWire just fine to deliver those same tricks, but ProcessWire’s role in that ends at helping you manage and assemble the data for your response. Admittedly I’m still not certain what your clients’ goal is. You have a clickable link in a sidebar and want it to open in a new tab, but somehow it also involves a redirect? Sorry I can’t be of more help, but I’m sure we can get it figured out if it’s at all possible.

Please explain what your client needs users to experience in more detail.