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?