rick

@Christophe I had too many redirects at one time in the past which was due to the same thing you are trying to accomplish. With my registrar, the dns option to redirect using a wildcard, such as *.domain.tld (www.domain.tld) to domain.tld covers the initial redirect. Then you can leave the htaccess file to change http to https. This resolved the issue for me.

Do that all the time and you won't go wrong.

Yes. Any time you create or retrieve a page, whether it is a User type or any type of Page object, you should turn off output formatting before you save the data. For example: // new user, or any type of page object $u = new User(); $u->of(false); // turn off output formatting // assign data to fields $u->save(); // existing user, or any type of page ovbect. $u = $users->get("username"); // replace username with the name of a user $u->of(false); // turn off output formatting // assign data to fields $u->save(); ProcessWire will automatically turn output formatting on again after the save completes.

Those ridiculous, downright stupid, pointless and idiotic EU Cookies taste like crap.

I'm sure there is a ProcessWire way to do it, but I'm not skilled enough yet, so I settled for a document tree that looks like this: /home/policy/tos /home/policy/privacy /home/policy/aup ... which presents urls like, domain.com/policy/tos, etc. Those pages use the 'policy' template so that I can select or exclude them depending on which menu I'm rendering.

User submitted data is nothing more than a group of fields that define the type of data you want to save, such as text (user name), images (avatar), etc. Those fields are then assigned to a template, which is nothing more than a grouping definition for those fields, eg, user name, address, etc. That template is then assigned to a page, which is basically the interface between the user and the database. You code how you want the user data entry form to appear, assign each data element to the appropriate field, then save the page. You use the current user (the one logged in) to determine which page to display. For example, $pages->get("page->createdUser = $user->id") returns an array of pages that $user created. No other user will see it, nor can they hack it. Your code determines what is accessible. You can define additional permissions using those modules mentioned earlier to further restrict what any particular user may do or not do. For example, if ( $user->hasPermission('whatever') ) { do something }.

Hi @Thor What I said about the author may not be the actual name. I think it is $page->createdUser, which indicates the user (author) that created that page. Sorry for my broad terminology. And Yes, page edit field permission module is a finer control over access. When you say 'submitted data' that implies a form action, either front-end or admin, so yes, you will need to code for your specific conditions. For example, User-A submits whatever through your front-end form. Your code will need to sanitize that form data, then save that data to the desired page. After you process the form data, and before you save the data, you can specify other properties, such as created user, or whatever fields you defined for that template. Later, you can retrieve one or more pages that the user created, or has access to, or however you define it, for whatever purpose you intend. That means User-B won't see what User-A has done. You could also retrieve all pages, regardless of user, to display to any user if you desire. Take the case of a user profile. ProcessWire, by default, only shows the profile data to the current user, and not another user. But it doesn't prevent you from retrieving all user profiles and displaying a list to any user if that is what you want to do. As I re-read your initial post, it is clear that you do your research. What you are asking for your project is very doable in ProcessWire. Even if you find you need to create custom tables, ProcessWire makes that very easy to do -- see the wire database pdo. There is a ton of information in this forum as well as the normal API reference, captain hook, etc. Should you have any questions during your development, there are many far more talented members here that will be glad to jump in and help out.

@Robin S This. This right here is why you are a hero member. Props to you for the profile explanation. I never knew the procedure. I will put this into practice immediately. PS. Where is that damn "Buy-a-Beer" button? Somebody needs to make that happen.

@szabesz, I will let @justb3a address this. But it won't affect the functionality, only the w3 validation.

Couple of questions... Why use a label for a hidden field? Is the date field to track when the user submits the form? If so, it is not necessary. You can set the date when you process the form.

Your site loads fine for me (chrome) when first entered in the address bar. One thing I did notice is each menu item is prefixed with 'Header:' in the title field. Nice site by the way. Costa Rica here I come.

I'm not knocking sendgrid, or any other email service. After working in the adult industry (I know, don't judge me. I was young and needed the money ), I am not too fond of services that want a 'contacts list' stored at their site. You may want to consider gmail, or the like, for sending small quantities of emails. If you need an email company domain, eg, yourname@yourdomain.com, then they will provide that for a small monthly fee, usually $5 or so. I have never exceeded gmail's limit, and it is far better than trying to run your own email server. Also, the majority of my applications require subscribers to use their company email address. I have the company create a site admin email address on behalf of the application, which eliminates the need for any third-party solutions. If you need the capacity of those email services, then by all means use them. They handle that particular need well. Just be cautious of how they treat your contacts, if they require it. Another possibility is to move to a VPS hosting account that has an email feature. That way you are the only user that they audit to affect any email limitations.

@Robin S, Care to share your site profile? Did you modify the default site profile for installation? How did you do that? I would be interested in creating a 'pre-configured' 'blank slate' so to speak.

In addition to a server's basic specs, another consideration is bandwidth/memory surges. Does your hosting company limit you to only x-GB per month (without burst) or do they offer bursting coverage as well? That price seems a little high to me regardless, ie, You can co-lo for that price. Also, (and I know you are aware of this) the way the code (and queries) is written can play a big part in memory usage. On a related note, I have a co-lo machine that is a dinosaur compared to today's systems -- It has 256M or ram, single processor, and runs all the pre-processwire applications I have written (hundreds of user connections) without a single hiccup. The code written utilizing ProcessWire can be done inefficiently, for example, using $page->find when $pages->count is the more efficient call.

The answer is; It depends. ProcessWire permissions are Field/Template specific. Out of the box, you can define which roles/permissions apply to any field or template (see Access tab). When you create a field and assign it to a template, its 'data' is subject to the access control you defined, or it's parent, if none is defined. Ryan wrote another module to expand on this functionality here. Also, you can test the author id of a page whether it matches the current user in order to limit access. The thing I have learned in my short time working with ProcessWire is that there are many ways to accomplish what you want. But that is the second edge of that sword in trying to decide the best approach for your needs. So the bottom line is, if you want some data to be restricted, then you restrict access. That isn't meant to be a flippant answer, rather to show that you can make things as simple or complex as needed. ProcessWire doesn't limit you. BTW, welcome to the forums!

header("Status: 401", true, 401);

Hello all, I am evaluating phpstorm and would welcome any comments from those of you that use it. Here is screen shot of a namespace test. Ex 1 shows undefined variables, user, session, and pages. No autocomplete is available. Ex 2 shows undefined functions, isLoggedin and redirect. No autocomplete for methods is available. Ex 3 shows a correct validation and autocomplete is available. I am not sure how to configure phpstorm so that I write as shown in ex 1 and have it validate as in ex 3. Any help is greatly appreciated.

I use this format: If form submitted { if CSRF is valid { // process form data } else { session redirect 401 } } // render form The reason I use this order is, First, I make sure the form was submitted. If it was not, then render the form. Second, I validate CSRF. If it passes, then process form data. // No sense processing form data if invalid. Lastly, if CSRF fails, I redirect to 401.

I'll assume those are two separate code snippets... In the second snippet, you are assigning the page array to $events, but you are referencing $single from your first snippet. Also, these lines '<span class="day">{echo strftime("%d", strtotime($single->Start_date))}</span>' should not have {echo. I believe you use {} to enclose echo'd variables, and not functions. <-- Don't quote me on that. There is also a mix of shorthand (<?=) and regular (<?php echo). I would use one style everywhere to make it easier to read.

Having such information presented publicly is a great idea to help promote ProcessWire. Thanks to @benbyf for taking the initiative. The newspaper writing style certainly helps with content such as this. My only concern with this article is the wording. This is meant only as constructive criticism. #1 The way it is written, it implies that for some unknown reason ProcessWire (not the user) had created an arbitrary number of images within a page, and now you may want to remove them. To a new user, or prospective user, it implies they will have maintenance issues when working with ProcessWire. We know this is not the case. This tip's opening sentence might be more accurately written like so, 1. Bulk Delete Images in Admin As you create your site content, you may have added any number of images to a particular page that are no longer wanted. Should you want to get rid of them... #2 This one really sticks out. The means by which a user gets 'locked out' is due to either pilot error, or an interruption in a critical process, and rarely due to some internal malfunction. It might be better to have written it like so, 2. Regain Entry to Backend For those times where you may have forgotten your administrative password, or if a poor network connection caused a critical process (like a site migration) to fail, you can reset the administrative password using this simple trick... #3 Specifying a heading "Upgrade ProcessWire" and immediately opening with "Upgrading is a chore..." doesn't give a good first impression. While that statement is technically accurate, it might be better to lead with how simple the ProcessWire upgrade procedure is in relation to the complexity found with other platforms (without naming names). /$0.02 Like I said, these are simply my comments meant as constructive criticism for future articles. Giving a good first impression is critical to our growth. I know there is no style guide associated with ProcessWire-related articles, so it might be a good idea for anyone wanting to write such articles in the future to ask a staff member to proof read it before publication for things like grammar, inflection, conveyance, etc. And again, thanks to benbyf for making this contribution!

Hi @franciccio-ITALIANO, If your database was deleted for some reason, then ProcessWire will have no internal data (created during install) in which to reference. That means your admin login does not exist, nor the admin url, nor any other information. I'm afraid that you will need to re-install ProcessWire to use the new database. Since the previous database was deleted, so was the previous content, and any fields/templates/pages that existed before. The only information not specifically related to the previous database are the files in the /site/templates/ folders. You should copy those to a safe location before you re-install. I hope you are in contact with @3fingers on skype. He can help you, as he speaks Italian. I would talk with him first before you proceed with the new installation in case I have missed anything.

Yes. I was thinking about the new users. We seem to be getting a few new members in the forum, which is great! I wonder how many have looked at the site without yet joining.

haha. They seem to be kickin' my behind lately.

Yes, that is what I thought. But it's now Tuesday.

What is the time frame for the downloads page to reflect the current version? It still indicates 3.0.61 as master and dev.