ErikMH

Thanks for your response, @kongondo! To answer your second point, I had indeed thought that ProcessWire variables were global — but since neither the $config nor the $session variable actually were accessible in my function (see the errors), I researched and found that:

Quote

A variable declared outside a function has a GLOBAL SCOPE and can only be accessed outside a function

— https://www.w3schools.com/PHP/php_variables_scope.asp

That source then went on to explain that that’s what the “global” statement is for. And in fact, adding “global $config” to the function solved the problem for $config. But when “global $session” did not solve the problem for $session, I posted here looking for guidance.

Thank you for the pointer to wire, which I’ve never heard of and which didn’t come up in the entire day that I spent searching the PW docs, blogs, tutorials, and forum. I’ll experiment with wire('session') and see whether that solves my problem.

I’m loving ProcessWire itself, but the layers upon layers of documentation and forum posts and blog articles that you have to wade through in hopes that someone has been kind enough to provide a link to the information that you really need is very frustrating.

So, if I do this right at the top of a template PHP file:

<?php
	namespace ProcessWire;
	function myFunction() {
		global $config;
		echo $config->dateFormat;
	};
?>

I, predictably, get this in my front end (once I figured out about the necessary global $config; line):

Y-m-d H:i:s

Happy camper. But if I try to access $session variables in the same way:

<?php
	namespace ProcessWire;
	function myFunction() {
		global $session;
		echo $session->future;
	};
?>

I’m told there is no $session object; it responds exactly as if I hadn’t included the global $session statement:

PHP Notice: Trying to get property 'future' of non-object in .../public/site/templates/home.php:5

I thought the problem might conceivably have to do with my private variables, so I tried the provided hasCookie() method:

<?php
	namespace ProcessWire;
	function myFunction() {
		global $session;
		print_r($session->hasCookie());
	};
?>

With essentially the same result:

Error

Call to a member function hasCookie() on null

$session variables and methods are fully accessible and work exactly as expected if placed immediately outside of myFunction().

I am rapidly running out of hair. Is this intentional? Or a bug? Can anyone confirm that they see this behavior? Can anyone think of a workaround? Thanks!

ProcessWire: 3.0.179
PHP: 7.4.19
 

@elabx and @netcarver, thank you both so much for your detailed and well-reasoned responses. These were just what I was hoping for! As I said at the outset, I do appreciate PW’s flexibility — but it does mean there’s a lot to process mentally before really getting going on one’s first project.

Of the four strategies you mentioned (a repeater, a table, child pages, and a repeater matrix), I think I’d have to agree with Netcarver that a table or a repeater matrix sound like the best match for my needs. Child pages (though a fascinating approach that I hadn’t thought of) won’t work because I do have another need for the page hierarchy. And repeaters just don’t “feel” right somehow.

So while I mull that over, does anyone have much experience with ProFields TextAreas? I stumbled across these yesterday, and have experimentally set one up to hold a batch of “note”-type TextArea fields — very similar to Ryan’s example — and it’s working really well with my half-dozen test pages. Again, it “feels” like this might also be an excellent match for my needs with Text fields, but I’m curious as to why you didn’t suggest it. (Simply not having thought of it is a perfectly acceptable answer, of course: So.Many.Options!)

Thanks!

ProcessWire is unopinionated. I get that. It’s a good thing.

And yet, this lack of proscription can be bewildering to newbies like me who struggle to figure out how best to accomplish something — even a simple something.

Case in point:

I’ve created an “organizations” template, and have added a couple of obvious fields to it (sortTitle (fieldText), address (fieldStreetAddress), etc.).

Now I realize that I have a bunch of similar-but-distinct bits of information that I’d like to store for each organization — basically, various competing “unique identifiers” such as PURLs, DOIs, ORCids, that kind of thing. Each organization will have 0–n  of these, and I’m sure that over the years, more such IDs will crop up, and I’ll want to easily add new ones.

1. So, I could define lots of different FieldTexts (one for each type: ORCid, DOI, etc.), most of which would be empty for most organizations. And then I could continue adding new ones over the years. This seems less than graceful.
    
2. Or I could (I think) define a repeating field — though I’m pretty sure that would allow me to collect values of such IDs, without saying what kind of ID each was (am I right?), so that wouldn’t be a good plan.
    
3. Or I could define a FieldSet, which might be more efficient (since it’s just one field), but would have the same long-term drawbacks that using lots of FieldTexts would have.
    
4. Or I could use a ProField Table … I think. (I’ve purchased ProFields for other reasons, so I’ve no reluctance to go this route if it makes sense.)
    
5. Or I could create a “Unique Identifier Code (UIC)” template with N FieldTexts defined on it, and could create a new UIC page for each organization that had any kind of UIC.

I’m sure there are more options, too — possibly including the best choice. I’ve read (and done!) many of the tutorials, dozens of full forum threads, all of the relevent official documentation, and many module descriptions … and I feel like I know less than I did when I started.

So my questions are two:

1. What would you do — and why?
    
2. Is there somewhere where the community has assembled a list of broadly-agreed-upon best practices for ProcessWire development? Something along the lines of Ryan’s PHP Coding Style Guide?

Thanks in advance for all constructive suggestions. I’ve now read a lot of threads in this forum, and I have to say that I’m very impressed with the friendliness of the community, and with the exceptionally high signal-to-noise ratio here. I’ll try not to add too much noise!

Thank you so much for your quick response, @Mike Rockett! Long-time developer here, but very very new to ProcessWire. I’d suspected I was calling the module in the wrong way — and clearly I was right! So, thank you for adding the new method, but in fact I’ll look into configuring the field to use it as a formatter; I’ll bet that’ll be more efficient in terms of caching (and using a reference!) than what I was trying to do!

I’m loving ProcessWire, but there’s a lot to learn....

@Mike Rockett (& others), I think I must be missing something obvious here. Using the standard modules installer, I’ve installed Typographer 1.0.0 into my PW 3.0.179 installation (PHP 7.4.19), and configured many of its options. Two examples: smart quotes and smart ordinals.

Following the example of TextformatterMarkdownExtra (which I have working), I “get” the module:

$typ = $modules->get('TextformatterTypographer');

I then want Typographer to process the contents of a field “vsDetails” (in $item):

$details = $item->vsDetails;
$typ->format($details);
echo "<p class='news'>$details</p>";

All this seems to work without error, but $details is echoed unmodified: foot symbols used as apostrophes remain “'” and “2nd” remains unchanged (the “nd” is not superscripted).

The whole site is in debug mode; Tracy is installed (but I don’t really know how to use it yet). If I make other changes to the page, they’re immediately apparent, so I’m pretty sure caching isn’t an issue. (And just to be sure, I deleted the contents of /site/assets/cache/ )

I see that it’s possible to turn Typographer off for certain elements and classes; the text I’m feeding it is not from any of those, but I’m really not sure how it would know one way or the other. I’m taking this as another sign that I’m missing an important concept.

FWIW, I can run the TextformatterMarkdownExtra module on the same text in the same way, and it works perfectly.

Thanks for any help or pointers you can give!

As things stand, is it possible to get the same sort of functionality for auto-compiling .less files for front-end CSS — like, put the .less files into the right place and add a line to config.php?

If not, I see hints of how I might begin to script that sort of thing in @ryan’s post, but I’m sure I wouldn’t be able to figure out the fancy timestamp checking, &c. (Old-school applications programmer/systems analyst here, but still pretty new at PHP, Unix, &c.) I’m game to experiment, if someone could point me in the right direction.

Thanks!

I’m a nearly brand-new ProcessWire user, and I’ve got to say I’m really impressed — not just with this functionality, but with how easy @ryan and @bernhard have made everything. I installed the new version of PW on my cloud server, installed the Less module, updated config.php and put a few Less statements into admin.less — and had it all working perfectly within about 15 minutes. Nicely done!

Ooh, thank you for this pointer, @wbmnfktr. I’ve done just what you suggested!

Excellent, @elabx — thank you again. It turns out it was the fingerprinting (not the sessionChallenge) — and I’m guessing it’s because I’m using Cloudflare’s 1.1.1.1 WARP for my local connection. I’ve removed the sessionChallenge override, and moved the sessionFingerprint line down in site/config.php to the spot that would correspond to where it is in wire/config.php. Everything’s still working, so I’m happy and I’ve learned something. Thanks!

Onwards, through the fog!

31 minutes ago, elabx said:

Can you try on site/config.php:

$config->sessionFingerprint = false;
$config->sessionChallenge = false;

 

Those were not in the file to un-comment, so I added them. Not knowing where to put them, I put them at the very top of the file.

And — bingo! — I can log in! Yea! Thank you!

Now.... Can you tell me what I’ve done, why those lines weren’t already in the file, and where I should actually put them in the file?

17 minutes ago, adrian said:

Sorry if this is a silly / obvious thing, but please note that setting the page name for the admin to xyzzy doesn't also set the admin/superuser's name to xyzzy as well. Did you explicitly set it to xyzzy as well?

Not at all — that’s an excellent question. I did explicity set it that way — but you’re right: I should’ve explicitly mentioned it here. Thanks for thinking of it!

I’m new to Processwire. I’ve installed the current release version at my very-long-time (25 years) host, pair Networks. MySQL db is created. Installation process completed with no errors.

I’m now trying to log in. Rather than taking the default `/admin` suggestion, I chose `/xyzzy`. When I go to `example.com/xyzzy`, PW displays a login screen, as expected. I enter the username (`xyzzy`) and password that I assigned (and copied and stored in 1Password) in the installation process (five words separated by hyphens). So far, so good.

I would expect then to be taken to the admin pages. Or (if I got something wrong) to be given an error message. Instead, I’m taken to the URL `example.com/xyzzy/page/?login=1`, which as far as I can tell is exactly the same as the initial login page. No error is given.

I grew so frustrated by this, that I deleted the entire installation and the MySQL database, re-downloaded PW, installed it again using a different username and password for the admin account.

And I’m seeing exactly the same behavior. Time for me to ask you experts: WTF?

Many thanks for any insights you may have....

5 hours ago, ryan said:

PW actually implemented this ability last year (meta data and stored image dimensions)

It took me a while to find this; I thought I’d link to it in case others wanted to see it:

wbmnfktr is right that there is a Bitnami folder. By default on macOS, you’ll find it hidden at ~/.bitnami — though I can’t tell you about other systems. However, you won’t find your standard ProcessWire folder there. Instead, you’ll need to do the following:

1. In the Bitnami ProcessWire app, go to the Volumes tab and tell “/opt/bitnami/” volume to mount (see attached screenshot).

2. You should now find an NFS volume mounted in your OS (by default named with your Bitnami ProcessWire’s server address). There’s useful information in the /bitnami/README.txt file on that volume.

3. You’ll then want to head on that volume to /bitnami/apps/processwire/htdocs/site/ — this is where you’ll find folders for your site’s assets, modules, and templates. Despite the reference to “exported” in the Bitnami window, it’s “live”: creating a new template file in the templates folder will make it available to your running ProcessWire server.