teppo

Should also be noted that there are multiple ways around this, depending on the larger context and your needs: If the booking system provides support for event-based actions and you need real-time data for your ProcessWire site, you could do what adrian mentioned above; make the booking software bootstrap ProcessWire and create new pages (or populate ProFields Table field or a custom database table of your own) for your reservations. If the reservation data doesn't have to be real-time and you have proper control over your production environment, you could create a cron job to fetch data from the booking system (assuming that you have access to it via an API or database). If you only need the data for view purposes and have access to the database that third-party booking app populates, you could just use ProcessWire's $database API variable and query it on the fly. The most important considerations here are a) do you need the data to be real-time and b) can you tap into the third-party systems events in order to bootstrap ProcessWire, does it have have a public API you can query, or do you have direct read access to its database.

Hi. Me. On just about all sites I've built in the past few year, both my own ones and those built for clients. Layouts consisting of blocks or "widgets" created via PageTable or Repeater fields have their use cases, but for regular content CKEditor works just fine and provides a sensible balance between flexibility and structure. It's true that getting CKEditor to behave takes a little bit of effort, but on the other hand I've noticed that most people familiar with the eccentricities of Word tend to be very much at home when it comes to CKEditor I've use Hanna Code in some specific cases, but to be honest it hasn't really been that helpful. Most non-technical users prefer the interface of CKEditor ("it's like Word") and strongly dislike anything that feels like "coding". Even those users who get it tend to forget which snippets the site has and how they work (which is why I built the Hanna Code Helper module in the first place). Like Joss already pointed out, it really depends on what you're building, and for whom.

PageTable is particularly handy if you need control over where the data is stored. Repeaters handle this part automatically behind the scenes, but with PageTable you have more options, such as making stored items children of current page, etc. In some cases the UI of PageTable is also preferable. Of course there's also the free vs. commercial point of view: with PageTable you get the multiple templates feature right out of the box, but with Repeaters you'll have to get the (commercial) Matrix version in order to pull that off.

The problem is very likely something not visible in your post above. Testing with the setup below, I had no issues getting this to work under latest version of the devns branch: <?php # /site/modules/TestHook.module class TestHook extends WireData implements Module { public static function getModuleInfo() { return array('autoload' => true); } public function init() { $this->addHookAfter('WireHttp::send', $this, 'hookCheckAuth'); } public function hookCheckAuth(HookEvent $event) { die("dying"); } } <?php # /site/templates/basic-page.php $http = new \ProcessWire\WireHttp; $http->send('/');

(Sorry, couldn't resist. English is such a wonderful language, don't you think?)

Thanks for updating the roadmap, and a Happy New Year to you too, Ryan! We've got some great things coming this year, no doubt about that Though we might want to discuss this eventually in a separate thread, inspired by Mike's comment above here are some initial comments regarding the site redesign. I'm trying to be as constructive as possible here, so please forgive me for just stating negative things; there's a lot of good too, but right now I feel that it's more useful to point out things that don't feel quite right. I've mentioned this before, but what I would love to see would be more clarity in regards to navigation and structure. For most parts those are the same thing, but there are also things that are only related to one. The visual side of the site could perhaps use a facelift too, but I wouldn't consider that a top priority right now; in my opinion there are more urgent issues to address, and the site doesn't feel all that outdated to be honest. Great design transcends time and so on Perhaps the biggest inconvenience for me is that the hierarchy of the site is not really reflected on the navigation. Topmenu items are not items at the top level of the page tree (except that some are), subnav items are often links to other sections of the site or completely separate (sub)sites, etc. One key strength of ProcessWire is the page tree approach, which makes structure sensible and easy to follow. I would like to see that benefit in action on our own site too. Other than that, I feel that the structure has pretty much grown in an organic way, and as a result of that things are not always where I'd expect to find them, and sometimes adjacent pages feel entirely different in scope. Some pages appear in multiple places, which can also get confusing, though in those cases they're usually redirects to somewhere else on the site. All in all the content architecture of the site doesn't feel very concise to me. In regards to the subnav, I would like to see some minor usability improvements in upcoming versions. For an example, the first item of the menu is actually the parent page, but visually it's in no way different from its children, which makes it less obvious than it could be. Also, while I still feel that a dropdown menu is often bad for usability and accessibility, it could also take away some of the pain related to "things not being where I expected"

Just checking, but.. is this the Markup SEO module?

Agreed. This is a surprisingly common gotcha for regular users. Opening the page tree again to unselect selection is not very intuitive.

You're making good points there, but to be completely fair that's your point of view. I'm not so sure that Ryan feels that way, and I certainly wouldn't. Even if it's just a question of committing some changes to separate repository and keeping track of two repositories for issues etc. in my opinion it seems like added workload and complexity compared to current situation. The point with .htaccess is that while you've suggested this as something that would make upgrading as simple as one git command, the .htaccess file is exactly why this isn't true: it may require manual changes, and thus that single git command is only a partial solution. Note that I'm not saying that making the index.php file a placeholder would be a bad idea in itself; I'm referring to the bigger context here. Finally, I believe that you can already upgrade your site with a "git pull". The only downsides I can see are that a) it won't upgrade index.php or .htaccess, b) you'll probably have a bunch of unnecessary site-* directories, and c) it will also pull in some other unnecessary files, like a htaccess.txt (.htaccess should prevent direct access to these). Please correct me if I'm getting something wrong here, writing this in a bit of hurry and probably not thinking everything through

Modesta actually works quite nicely with 2.7.2, as long as you install the latest version as an admin theme module. The issue with 3.x needs a bit more debugging.

Not much to go by there. Checking your site out did bring one new method to mind, though, so perhaps I'll be able to catch even these cases soon.. Probably need to make the rules visible on the isit.pw site too, so that people can actually prevent detection if they so choose.

What's even more odd is that this link gives me "yup". Either I'm doing something wrong here, or there was some kind of temporary glitch in connections or whatnot.

Use cases I've seen in the wild: Get a page at "/news/". Site admins have access to this page, and thus someone could replace a page in that URL with something entirely different, or unpublish it expecting it to disappear completely. Get a page matching user-defined search query etc. from URL-segment, GET param, or something similar. Selector is nicely sanitized, but that doesn't do much unless permissions are checked separately. The answer to "otherwise why would you get() it" is often as simple as "because I want to find one page." In other words it's used as a syntactic sugar for something like $pages->find("some-stuff, limit=1")->first(). To my best knowledge findOne() is rarely used, but there the potential for confusion is actually even bigger, just like we can see from Martijns reply above. You're absolutely right that there are no problems as long as the dev checks permissions manually. What I'm saying here is that in my experience so far this is surprisingly often unexpected behaviour. Some devs will assume that the system automatically skips over pages current user doesn't have access to. Whether or not that's a reasonable assumption is another question entirely. In a way this might be similar to "should content be escaped automatically": in my opinion it shouldn't, but numerous times I've had to remind others about properly escaping content before output – or in ProcessWire's case enabling certain field settings. Twig and other templating systems seem to gravitate towards autoescape, making output of raw content a conscious decision, which is actually a great design decision in that context. The whole get() vs. find() thing is probably just something to be more adamant about when instructing new users, but when I see a mistake like this made often enough, I tend to get worried. Obviously you can't avoid all such cases with a system as flexible and unobtrusive as ProcessWire.

Just sharing real-world observations. This is a point of confusion for some devs, including me, and thus I believe it makes sense to ask whether it's working as expected. As always, if the general consensus is that it works exactly as it should, then it probably does, and the disagreeing minority should just suck it up. Either way, when it comes to questions that involve security, I tend to gravitate towards the most obvious and fool-proof approach possible

Even if I generally speaking agree with WillyC there, I must also admit that get() not checking permissions does feel a bit off to me too. Additionally it's one of the most common mistakes I've had to correct in my code reviews so far: since find() by default skips over content that the user doesn't have permission to see, developers tend to assume that get() works in the same way. I wouldn't consider it a vulnerability, but I don't think it's entirely in line with some other features either, and in my experience it's proven out to be a common source of confusion and potentially harmful mistakes. These days whenever I explain ProcessWire's API to others, I tend to include a special note about get() vs. find() from a permissions point of view

If there were (known) vulnerabilities, this would be more important, but +1 from me for changing this behaviour anyway. In my opinion there's absolutely no need to disclose the specific version number

Labels are field-specific, i.e. generally they apply everywhere the field is used. Values on the other hand are always page-specific, i.e. each page has a separate value for each field. This is why you should be asking for the value of this field from a specific page. For current page you can use $page, and for other pages you can, for an example, do this: $pages->get('/page/url/'). <?php echo $page->caracteristicas_superficie; ?> <?php echo $pages->get('/page/url/')->caracteristicas_superficie; ?>Or: <?php echo $page->get('caracteristicas_superficie'); ?> <?php echo $pages->get('/page/url/')->get('caracteristicas_superficie'); ?>I would suggest taking a proper look at https://processwire.com/api/ before stumbling any further. The basic stuff is all explained there

@jmartsch, two notes about that: Session fingerprint is a security feature, and should only be disabled when absolutely necessary. In your case this might actually be the situation, pointing this out in case someone else reads this It's never a good idea to modify anything in the wire directory – instead of that, copy the directive to /site/config.php and change it's value there.

So far unable to reproduce this. With ProcessWire 2.6.20 dev (Reno theme) and PHP 5.5.21 mobile upload seems to work fine for me. The phone I'm testing with is Samsung Galaxy S6 Edge running Android 5.1.1 ("Lollipop"), and I'm using the native browser. One difference is that my sound recording app would only save mp4 or m4a, but this shouldn't matter at all for ProcessWire anyway. Edit: Did another test with a downloaded mp3 file just to be sure. No issues with that one either. Still unable to reproduce the issue.

Additionally knowing which version of Android you've tested with, and which browser you're using, would be helpful. There have been numerous bugs and missing features in the system, not to mention that even specific phone models sometimes seem to mess things up. I'll see if I can reproduce this using one of my own phones, though. So far it sounds like your phones are not sending the file extension properly, and in that case there are two likely scenarios: either the file didn't have an extension in the first place, or the file upload dialog (in your browser) is not sending it properly to the server. Hard to say without testing a bit more.

Not sure if I'm getting your question right, but why not simply check if the value of the field is an instance of PageArray: if ($page->field_name instanceof PageArray) { // iterate }

Your preference towards double quotes in HTML markup is purely visual. The browser doesn't care, users won't care, and if you enable minification via something like ProCache, it's actually possible that it might automatically remove some of those quotes altogether. In many cases the quotes are not needed at all, which means that they're just taking extra space. Regardless, my personal preference in PHP is to always use single quotes by default, and double quotes only if I really want to embed variables in the string. Using single quotes means that there's zero chance of accidentally inserting a variable, or really any string starting with dollar sign that would be interpreted as one. When I do want variables in the string, I prefer double quotes, though I also tend to use curly braces everywhere, regardless of whether they're "necessary": $editUrl = "data-mfp-src='{$page->editUrl}{$lang}&modal=1'"; Regarding editors: my opinion is that any decent editor should get highlighting right. If your preferred editor doesn't, consider switching. If syntax highlighting works in some cases, but not always, that's a potential source of confusion. In the end the style guide for ProcessWire is no different from other style guides in that many things there are opinion-based. If you don't want to use that in your own projects, you don't have to, but of course adhering to it could make working together with fellow ProcessWire users slightly easier.

@MisterM: first of all, great to hear that you're enjoying ProcessWire and the forum! To answer your question, I would simply use "Powered by ProcessWire". Seems snappy and obvious enough to me, especially if it's also a link to processwire.com

This is a valid suggestion. Here's a bit more about the same subject: https://processwire.com/talk/topic/3000-non-alphabetic-page-name/. I'm pretty sure that there is/was a GitHub issue about this too, but can't seem to find it right now.

Not saying that multiple branch support wouldn't be a cool feature for Admin Restrict Branch, but in case visibility is not an issue and you're looking into ways to restrict permissions per branch, I would also suggest taking a look at UserGroups and Dynamic Roles. The approaches are slightly different, but both modules already provide support for this.