pjg

Couldn't have put it better. Azure's CDN offering has recently become a heck of a lot more reliable as well. In my opinion not quite on par with AWS in some areas, but worth comparing.

After some more testing I have now discovered that the following hook called at line 107 in ProcessUser.module is in fact not doing anything and the superuser role is shown to all users who are able to assign roles to users. The hook is defined from line 115 in the same module file. public function ___executeEdit() { if(!$this->wire('user')->isSuperuser()) { // prevent showing superuser role at all $this->addHookAfter('InputfieldPage::getSelectablePages', $this, 'hookGetSelectablePages'); } $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'hookPageEditBuildForm'); return parent::___executeEdit(); } public function hookGetSelectablePages($event) { if($event->object->attr('name') != 'roles') return; $suRoleID = $this->wire('config')->superUserRolePageID; foreach($event->return as $role) { if($role->id == $suRoleID) $event->return->remove($role); } } public function hookPageEditBuildForm(HookEvent $event) { $form = $event->return; $theme = $form->getChildByName('admin_theme'); if(!$theme) return; if(!$theme->attr('value')) { $theme->attr('value', $this->wire('config')->defaultAdminTheme); } } Any ideas anybody? I work with hooks a fair bit, but this one has me stumped completely. EDIT: I know the hook is never called, but I don't get why since InputfieldPage::getSelectablePages as far as I can gather is in fact called to create the list of roles.

After some significant head scratching and frequent application of forehead to desk I might have found a solution for this - in theory at least. The idea came when I realised the system already hides the superuser role from non-superusers. Since this is achieved in a hookable function (my life saver on many occasions) within ProcessUser.module I should be able to add some form of check for role pages that have status hidden applied and remove them from view for non-superusers. In the long run I can then move to ensure the hidden roles are shown to superusers differently and possibly prevent them from being selectable, but for now this should work. Will confirm for anybody interested once I've had a chance to spin up the dev environment.

Morning all, I've had a bit of a strange request from a client and was wondering whether anybody has had any experience with this: "At the end of each year our member list will be purged and we would like all members to be moved to be grouped so they can be identified as previous members for communications and other purposes. This process should be fully automated and no manual alteration or intervention should be necessary or allowed once the members have been moved. We cannot move the accounts themselves as all returning members would still be members of the 'alumni' group(s) as well as the current membership." While I have no issues with automation of this etc I am slightly puzzled by the "no manual alteration" part as using roles does not allow me to prevent superusers (or the membership admin or the generic admin) from altering the roles and therefore adding or removing a custom role that satisfies the requirement. Creating a page somewhere that stores the information about the members of that year seems counterproductive since a role would do exactly that. So I guess my question is - can I create a "system" role that can be hidden or deactivated in the user edit screen and therefore prevent alteration at the user level. (At code level I'm not worried about any alterations being possible.) Any thoughts or comments are greatly appreciated including (but not limited to) ridicule for completely missing a point here. PS: Membership is added on an automated basis each year through a backend process, but a manual override has to remain in case of errors with their payment system. Hence why this had not been requested for the other roles.

Very nice implementation. Works a charm.

@Christophe: Naming wouldn't have made a difference as the files you include can be called almost anything as long as the code contained within them is valid php. As a matter of fact one of my standard include files is called "onions" (without suffix etc) purely because it amuses me when I can resolve an incident with the explanation that "I have lost my onions"... The latter suggestion merely provides context to human (and certain machine) readers, which in the final evaluation of the code is ignored by the server.

Hey Troost, welcome to the forums and pw. Can you post the code from the template file that is used for the page on which you are experiencing the problem?

Afternoon Jürgen, A million and one possible causes: a hook prepending output to anything rendered a rouge echo chucking out a space a simple error in the rendering page (that includes the doctype declaration) a space in an including tag etc. etc. Really without looking at code and systematically ruling out - or somebody who had the same issue with similar modules there's not a lot of hope for a quick fix. Phil EDIT: If you can find the template or include file that includes the line <!DOCTYPE html> that would be a good place to start the hunt. Most likely a head.inc or main.inc

Had to add a character counter with limiting functionality for one of my projects. Take a look and let me know what you think for now https://github.com/pjguk/MarkupSEO No guarantees given - this was "hacked" straight into a production environment which already utilises the module and therefore uninstalling and reinstalling was not an option for the time being. Particulars that are most likely not working as expected for now (Couldn't reliably test yet): Default character limits are not set on install Default character limits do not set should the limit field be empty when the page is saved Hard character limits do not apply to pages unless the fields are being edited and the page subsequently saved (requirement for my project, may not be the behaviour everybody wants/needs) So still some teething problems with the config on that part, but works well enough for me for the time being. The modifications allow the following: Counter added to the title and description fields in the SEO tab. Counting down from the limit to 0 - and beyond to show how many characters you are over. Config options in the module settings to set the character limits for title and description as well as toggling hard limits. Hard limits disable the ability to enter more than the limit number of characters. Useful if multiple authors work with the SEO tabs and you want to ensure nobody goes over the limits. With hard limiting disabled the character counter simply goes into the negative and ignores the limit for the actual input and render. With hard limiting enabled the input cuts off at 0 characters left.

Aye. MuchDev, are there selectors used in any of the included files. Especially ./includes/itemFunctions.inc raises my suspicions here if there is a function defined that is only used by this page. There are a few functions that appear custom ones, so that would be my next check.

Regarding the HTTPS option: $pageData['canonical'] = preg_replace('%^http%Uis', 'https', $page->httpUrl); should be $pageData['canonical'] = preg_replace('%^https?%i', 'https', $page->httpUrl); This way the regex will capture all of the protocol string regardless of whether it is http or https at this stage. In my case I got a httpss in the resulting links from the first one as it matched the http, when the input was https. Tried a few other regexes (e.g. https?, etc.) as well which logically should've worked, but preg_replace in its true self proved to be inconsistent. Scratch that - read over the U modifier. Fix returns https for both http and https as input, so covers both eventualities in the context of where it's called in the codebase.

Without looking at your code and just digging through the source it seems the error is thrown for an operator (i.e. the = or *= etc) being unrecognised. Since the function throwing the exception also has a nice debug entry it might help to run the template in debug mode and see what comes out of it. Quick glance over the code above does not flag up any major issues as far as I can see, but I'll take another look once I've drowned my brain in coffee.

Despite the annoyance of a lot of code - your best bet at getting a solid answer should be to post it since the error indicates some form of special character or otherwise malformed selector... Happy to take a look though.

In my Custom mod module (contains all the hooks that hook straight into the core, saving preventing me from modifying the core itself): wire()->addHookBefore('Session::init', $this, 'sessionInit'); # Session::init public function sessionInit() { ini_set('session.cookie_domain',".".wire()->config->httpHost); return; } Works a charm. Would be nice to have a config setting that allows cookies to be available for subdomains or not as this would make pw easier to integrate into existing projects. Although it could be argued that hacking two systems together should be made as hard as possible to stop people from trying it.

So after much head scratching and reading I've come up with the following solution - (minus the one pitfall I'm still working on as mentioned later): If a user access the "forum" domain, script checks for "site" cookies present If this is the case the script fires off a request to the site in the background with the cookie data being sent encrypted Server decrypts the cookie data, then fires off an internal request to the site with the cookie data sent using curl. Returns the user ID "forum" receives the site user id and "secret" key, then handles the request from there. While not the most secure way of doing things this does mean that the fingerprinting can remain enabled and is only specifically disabled for local request. The sticking point was trying to pass the cookies through curl correctly. One last (hopefully) simple issue - is there a way to change the cookie domain of the site to be .site.tld as opposed to site.tld in pw?

Having trawled through the various options: use ID of roles Custom PHP utilising ->hasRole use path of role I can display a list of users defined by a role (in the above ways), for a Page field, but no matter what I try I always get a failed save. Am I missing something? Have I misread the documentation and can't assign Pages under the admin section to pages in the non-admin section? Any help would be appreciated as I'm completely stumped. EDIT: Currently running 2.5.3 EDIT2: Soma's test script returns valid for all of the users using the above methods, invalid when using the role name (as expected). EDIT 3: On further testing it transpires that the only way I seem to be able to add user pages to the page field is via the "parent of selectable pages" setting. All other settings cause an error similar to Error saving field "assigned" - Page 41 is not valid for assigned whether used in conjunction or as a stand-alone. Final Edit: Resolved - issue caused by ambiguous description (see screenshot). It turns out that the selector alone is sufficient to display the correct pages, but without selecting the appropriate parent the pages would not add. Could I therefore propose (should this be the intended behaviour) that the description of the custom selector is updated to reflect this? The current wording of "rather than" implies that the selector option overrides the previous two and can be used standalone.

$session->redirect($page->path); As mentioned in the post you quoted the login handling code is supposed to be included in any page that is supposed to be protected. This means redirecting to $page->path is merely a solution to ensure the same page you are on at the moment is reloaded once logged in. At least that's how I'd read it.

Couple of cents from my end as I ran into similar issues a while back with one of my sites (the custom db and command line use): What http://processwire.com/api/include/ doesn't portray very well is the ease at which shell scripts handling a multitude of processing (in my specific case the automated processing of order emails to extract the order details) can be integrated by simply calling a php file. Command line php can take additional parameters, such as values extracted in the processing and handle them. Give me a shout if you want more info on that part. Database wise I've had to include custom tables alongside the pw structure for a variety of reasons. Where possible I tend to avoid adding tables though as part of the reason pw is as fast as it is lies with the way the database is designed and structured. However, where needed using custom tables is dead easy and doesn't impact directly on the way the pw queries behave (unless you overwrite the pw structure of course).

For a very elegant solution you could change the behaviour of the access control via hooking into the execute function of the ProcessPageView module. You'd either have to modify the behaviour of the checkAccess function (which isn't hookable, but you can define a replacement in your hook) to change the way the redirect url option on the existing templates behaves, or you could add an additional method by hooking into the ProcessTemplates module as well. I've got an example on one of my boxes, but can't access the files from here - will try and remember tonight. The usual disclaimer about relying on hooks as a way of changing core behaviour potentially causing issues in future releases applies. EDIT: The solution becomes elegant when utilising ESRCH's approach in the hook, in addition to modifying the login behaviour accordingly to handle the stored (or not) redirect session variable.

Wearing my non-pw hat for a second it is not uncommon for multimedia heavy sites (in my case large amounts of mapping) to be pre-seeded, usually using an automated routine written in an automation package (free ones are available and reasonably easy to use straight in the browser). This process in our case resizes, creates pyramids and initiates the cache. While this is overkill for 100 images and I'd agree with the solutions given by the previous poster, pre-seeding in this fashion is certainly an option for sites using vast amounts of multimedia.

I'm stuck on a specific problem trying to link a phpBB forum with a processwire site. Both are held on separate machines but can communicate with each other fine. I am easily able to validate a session on the phpBB side and log a user in on the processwire end if the session is valid and the user is linked. I am, however, stuck on remotely validating a processwire login session from the phpBB end. Since this is not a phpBB support forum my (more generic) query therefore is: Can I validate a file based processwire session remotely using nothing other than the Cookie stored session information? I have full access to both machines and can therefore work with static IP restricted pages etc, so security wise I'm not too worried, it's the how that baffles me at the moment. Disclaimer: Yes, I did search the forum and no I did not find anything useful to the given problem although I may well have searched for the wrong things... EDIT: I got as far as this "idea" Cookie data: 'wire' 'wire_challenge' Check 'wire' and 'wire_challenge' are valid, if so extract the user_id from the session Check the user_id is paired with a phpBB user on the pw system using the standard API, if so pass back the phpBB user id stored (Run the auto login on the phpBB end using the returned id - this is surprisingly trivial...)

For some reason hooking onto path didn't even cross my mind... sounds like the better idea though as url is dependent on path anyway and it would allow me to remove a workaround currently running for the admin pages.

I've been using pw successfully for a while now and for two of my recent projects I had to rewrite the page->url function. Since rewriting this in the actual core is not great for updates it would be great if the function would generally be made hookable. This allows for a more dynamic way of dealing with links and link rendering while, as far as I can see so far, not interfering with the actual functionality of the pw core. For the time being I'm more than happy to add my 3 _ to it and with the next update do it again, but it would be useful if it was there anyway.