kongondo

Tracy Debugger

Yeah, I had similar thoughts when drafting the module. This is quite easy to accomplish. Actually, one other reason the module is alpha is that it could end up being more than a multi site thingy, hence I would need to change the Class name. Cool idea. I'll have a think.

No, they are not different. I have not used ProcessExportProfile (but I've been thinking, how nice we have it; it will play nicely with ProcessMultiSites). I assume though that it exports the same type of profiles that ship with ProcessWire (the site-default, etc). so it should work. What I meant is that, say, you have a blank profile. You want to use that to install several sites. Those sites have different module needs. When creating a site you will be able to paste or select module class names to fetch (live) and install along with the site creation. I haven't thought it through properly and it would mean a delay while the modules are being downloaded.

Created a Process Module for this .

Sites Manager 16 September 2018: FOR NOW, PLEASE DO NOT USE THIS MODULE IN A PRODUCTION SITE. A RECENT ProcessWire UPDATE HAS BROKEN THE MODULE. I AM WORKING ON A FIX. ################ Sites Manager is a module for ProcessWire that allows Superusers to easily create/install ProcessWire sites on the same serverspace the module is running in. Only Superusers can use the module. You can create both stand-alone and multi-sites. Single/Stand-alone Sites Stand-alone or single-sites are sites that will run in their own document root/directory with their own wire and site folders, .htaccess, index.php, etc. In other words, a normal ProcessWire site. Multiple Sites Multi-sites are sites that will run off one wire folder (shared amongst two or more sites) each having their own site folder and database. In this regard, it is important to note that Sites Manager is not in itself a multiple sites solution! Rather, it is a utility that helps you create multi-sites to be run using the ProcessWire core multiple sites feature. For more on this core feature, see the official ProcessWire documentation, specifically the solution referred to as Option #1. Option #1 approach requires the site admin to initially install ProcessWire in a temporary directory for each new site. The directory then needs to be renamed as site-xxx, where ‘xxx’ is any name you want to use to differentiate the installation from other sites, before it is moved to the webroot. For instance, site-mysite, site-another, site-whatever. In addition, the /wire/index.config.php file must be copied/moved to the webroot. Each time a site is added, the index.config.php has to be edited to add ‘domain’ => ‘site-directory’ key=>value pairs for the site. This process can become a bit tedious. This module aims to automate the whole multi-site site creation process. The module is based off the official ProcessWire installer. Creating a site is as simple as completing and submitting a single form! You also have the option to type and paste values or reuse a pre-defined install configuration. The module will: Install a ProcessWire site in your named directory, applying chmod values as specified Move the directory to your webroot Update/Create a Superuser account as per the submitted form, including setting the desired admin theme and colour For multi sites, update sites.json (used by index.config.php to get array of installed sites) For multi sites, the only difference in relation to the core multi-sites index.config.php is that this file is slightly different from the one that ships with ProcessWire. Download from GitHub: Sites Manager (Beta Release) Features Install unlimited number of sites in one (multi-sites) or independent (single-site) ProcessWire installs. Install by completing a Form, Typing or pasting in configurations or using pre-created install configurations. Choose an Admin Theme to auto-install along with the site installation. For single-sites installation, download, save and reuse ProcessWire versions of your choice. Install and maintain site profiles for reuse to create other sites. Create install configurations to speed up installation tasks. Client and server-side validation of site creation values. Edit uploaded profiles (e.g., replace profile file). Lock installed sites, configurations and profiles to prevent editing. Bulk delete items such as site profiles, installed site directories and/or databases (confirmation required for latter two). View important site details (admin login, chmod, etc). Links to installed sites home and admin pages. Timezones auto-complete/-suggest. Pre-requisites, Installation & Usage Please see the documentation. Technicalities/Issues Only Superusers can use the module. ProcessWire 2.7 - 3.x compatible Currently using ProcessWire 2.7 installer (install.php) For multi-sites, potential race condition when sites.json is being updated on a new site install vs. index.config.php accessing the json file? Not tested with sub-directory installs (for instance localhost/pw/my-site-here/) Currently not doing the extra/experimental database stuff (database charset and engine) Future Possibilities Install specified modules along with the ProcessWire install Profile previews? Credits @ryan: for the ProcessWire installer @abdus: for the index.config.php reading from JSON idea @swampmusic: for the challenge Video Demo Demo showing how quick module works on a remote server [YMMV!]. Video shows downloading and processing two versions of ProcessWire (~takes 7 seconds) and installing a single/stand-alone ProcessWire 3 site using the new Admin Theme UI Kit (~2 seconds) on a remote server. Screens 1 2

That's the normal behaviour. Have a look at this thread for a solution:

Mod note: The OP was a spammer. They've been banned. The original thread is now here with Peter Knight as the OP.

My guess...Blog was installed without the demo content option (i.e. 'Blank Template Files' option was selected), so, no output

Glad you like it. What Mike said .

I suppose so. I struggle with the ML API to be honest and could do with some help. Do I tell PW to get the page (menu) with the title of the default language? Thanks for any pointers/code, ta.

Ahem...really Mike? ....the docs, Mike, the docs: Glad you got it sorted .

Hi @Zeka, Yeah, PHP 7 is a little more stricter. PHP 5 forgave such indiscretions . If you could open a bug report for me so that I don't forget to fix it, I'll appreciate it (along with other issues that have been recently reported). Thanks.

Both. A free (and decoupled from the back) frontend module and a Pro backend.

I can categorically assure you that this is not the case. Support or lack of support for a module is not a criteria for what modules make it to the core. I could go into details but I need to run.

What @abdus said. Here's another link to to the docs on internationalisation in ProcessWire.

OK, so I had a stab at this using $cache and ready.php. It seems to work fine. Throw the following code in ready.php or similar...The code and in-line comments are purposefully verbose to make it easy to follow. // Hook into login/logout sessions wire()->addHookAfter('Session::loginSuccess', null, 'checkLoggedIn'); wire()->addHookBefore('Session::logout', null, 'removeLoggedIn');// Hook before to get $user->id /** * Check if a user is already logged in * * If user logged in, take an action (notify,logout,etc). * Else, cache user as logged in to check for duplicate logins. * * @param HookEvent $event The object (Session::loginSuccess) we are hooking into. * @return void * */ function checkLoggedIn(HookEvent $event) { $user = $event->arguments('user'); $session = wire('session'); $userDuplicateLogin = checkUserDuplicateLogin($user);// returns boolean // if user logged in, do something. Here, we log them out and redirect to home page // you could make an exception for Superusers, or exception by role, permission, etc if($userDuplicateLogin) { $session->logout(); $session->redirect('/'); } // set cache else setLoggedInUserCache($user); /* @note: testing only $log = wire('log'); $log->save("user-logs","Successful login for '$user->name'"); */ } /** * Check if a user is logged in more than once. * * @param User $user The user to whose logins to check. * @return Boolean $duplicateLogIn True if user already logged in, else false. * */ function checkUserDuplicateLogin(User $user) { $cache = wire('cache'); $duplicateLogIn = false; $userID = $user->id; $cachedUsersIDs = $cache->get('loggedInUserIDs');// array OR null if(is_array($cachedUsersIDs) && isset($cachedUsersIDs[$userID])) $duplicateLogIn = true; return $duplicateLogIn; } /** * Create or update cache for logged in user. * * @param User $user The user whose cache to set. * @return void * */ function setLoggedInUserCache(User $user) { $cache = wire('cache'); $userID = $user->id; $cachedUsersIDs = $cache->get('loggedInUserIDs'); // cache does not exist, create empty array ready to cache if(!count($cachedUsersIDs) || is_null($cachedUsersIDs)) $cachedUsersIDs = array(); // save/update cache // for value, can use whatever, even $user->name; doesn't matter, key is the important thing here // outer array: we use $user->id to group same user; // in inner array, we use session_id() to ensure uniqueness when removing cache $cachedUsersIDs[$userID][session_id()] = $userID; $cachedUsersIDsStr = json_encode($cachedUsersIDs);// JSON to save as cache $cache->save('loggedInUserIDs',$cachedUsersIDsStr);// @note: set expiration of cache if you wish to } /** * Remove a logged out user's cache. * * This to allow subsequent logins. * * @param HookEvent $event The object (Session::logout) we are hooking into. * @return void * */ function removeLoggedIn(HookEvent $event) { $user = wire('user'); removeLoggedInUserCache($user); /* @note: for testing only $log = wire('log'); $log->save("user-logs","Successful logout for '$user->name'"); */ } /** * Remove the cache for a user who has logged out. * * @param User $user The user whose logged-in cache we are removing. * @return void * */ function removeLoggedInUserCache(User $user) { $cache = wire('cache'); $userID = $user->id; $cachedUsersIDs = $cache->get('loggedInUserIDs'); // cache does not exist/empty, nothing to do if(!count($cachedUsersIDs) || is_null($cachedUsersIDs)) return; // save/update cache // @note: we check for current logged in user but we remove the whole user group (outer array) // this is because the user logged in 'validly' is logging out. if(isset($cachedUsersIDs[$userID][session_id()])) unset($cachedUsersIDs[$userID]); $cachedUsersIDsStr = json_encode($cachedUsersIDs); // save updated cached $cache->save('loggedInUserIDs',$cachedUsersIDsStr);// @note: set expiration of cache if you wish to }

Maybe how PW checks if the same page is being edited in a different window could be of help? Have a look at the method checkProcessKey() in SystemNotifications module.

I get the "FieldtypeXXX" does not exist as well...during regular login. I always assumed it was due to my setup. I symlink my modules folder to be shared amongst a 2.7 multi-sites site, a normal 2.8 and normal 3.x installs. However, I also see it sometime on a machine with 3.x only. I'll try to keep an eye on it.

Thanks for reporting @Tom H. Looking into it.

Not what you asked, but assuming that you will be using these (or their variants) nutrition name, quantity and measure over and over, typing them in a textarea field and using some regex magic to split them up is probably not the better solution. In addition, typing the stuff up every time is tedious. I'd go for page fields or fieldtype options, or better yet, since you are grouping items, repeaters or even better repeater matrix or table combined with page field (for nutrition name) + integer (quantity) + fieldtype options or page field (measure). The latter modules are paid modules but well worth the spend. Using this approach, not only do you throw out the need to use regex, you also get the benefits of a clear presentation, user friendly/easy to edit, easy to add and remove items, searchable items, etc.

You are right. Yes, and we are working to resolve it. You've been a great help so far, reporting the spam, thanks!

Cool idea! But it seems the requirement is also to automate the process?

I haven't looked at your code closely, but if you need to write to a file, you need to write to a file. You have file_put_contents and fwrite. I see no other way around it irrespective of the software you use. ProcessWire itself writes to /site/config.php/ during install. I use this multi-site setup myself. I've been meaning to write some code or a module to automate the process but never got round to it. You could do with some error checking and backing up the original file as part of the updating the file.

@Zeka, that's a different method. That add() is for adding a new page to a specified parent and assigning it a given template. The add() @celfred is referring to is the WireArray method documented here and as seen here. It adds an item to the end of a WireArray (and its derivatives, e.g. PageArray). @celfred It shouldn't add without a save. There's something funky going on in your code. It's hard to pinpoint where because we can't see the original code. Maybe there's some other save or $real is being overwritten somewhere. I've tested your pseudo function and it works as expected in both PW 2.7 and PW 3.0.71. If I pass $real as false, the $page is not added to the Page Field. Btw, though made up, this variable name will throw an error $new-eq

Yes. Maybe your annual subscription expired?