Leaderboard

Hi @netcarver, the combination of installation salt and password reset finally let me log in. The rest is easy though annoying work, but stupidity needs at least mild punishment. Thanks a lot for your help!

Hi @rash You will need the salt from the original config file in order to allow existing users in the DB to log in with their current passwords. However, you can use the Recipe here for resetting an admin account password: https://processwire-recipes.com/recipes/resetting-admin-password-via-api/ That should, at least, let you log in as admin and use the interface. You might also try installing the ForgotPassword module in order to let other users reset their passwords.

You have a couple of options: You can create the required fields (and templates, if any) programmatically in the install() method of your module (see the documentation). Creating fields through the API is pretty straightforward, though you might have to dig a bit to find the properties you need if you want to customize the field's settings. In this case, you should probably also handle removing those fields in the uninstall() method so your module can be uninstalled cleanly (make sure to warn the user that uninstalling the module will remove all of it's data in this case!). The benefit of creating regular fields in your module is that your module's data can be managed through ProcessWire's regular interface, and you don't have to provide your own custom interface for simple CRUD operations. An approach that might be better suited if your module is targeted at developers is to make the fields to be used for storing data configurable. You can build module configuration options to let the developer select which templates and fields are used to store the data your module uses. Though this doesn't work for every use case. Finally, you can bypass regular fields entirely and store your module's data seperately. The advantage of that is that it's easy and quick. The downside is that you will have to provide your own interface for displaying and editing your modules data. Of course, that doesn't apply to every module – for example, you wouldn't need an editor interface to edit a user's cart. But if you store completed transactions, your module users will probably expect an interface to list (export, edit, delete, ...) all transactions, at which point you would have to build your own interface for that. Where you store the data is up to you: In the session or cookies (only for ephemeral data, like a cart). In a page's meta() data. I do that in some of my modules, see my post here. You can also use a custom database table for more elaborate storage capabilities. Again, you would use the install() and uninstall() methods of your module to create and (optionally) tear down your custom tables. See this post for some examples. Personally, I prefer modules that adopt best practices of the system they're build for – in the case of ProcessWire, I'd say it's best practice to create regular fields and templates instead of custom tables. But the ultimate answer is – as always – "it depends".

Unless things changed lately, MAMP activates OPCache by default. Make sure that the following settings are the same in your php.ini: opcache.validate_timestamps = true opcache.revalidate_freq = 0 Also check in MAMP config settings if caching is enabled for PHP (not sure if that option is still there, but with PHP 5.5, you could enable frontend caching).

As a designer with limited development experience who found PW a few years back, I can say this discussion has been very encouraging to read. PW has enabled me to make functional sites, but this thread opens my eyes to what’s possible. The last thing you want as someone not well versed in the intricacies of programming is leaving a client in the position of being hampered by the original decision in choosing a platform. For instance, anyone with a non-biased eye can see the real pain die-hard proponents of Webflow vocalize on their community forum. It’s come to an impasse. Whether it’s the limitation of the number of custom fields, or of the number of related records one can have, or the speed of queries, or the responsiveness of the dev UI slowing to a crawl because even a small dataset can make building a site laborious. PW eliminates those pain points. The challenge is communicating its value to a wider audience. My forte is communications, strategy, and brand building. So I tend to look at brand voice as part of evaluating a product or service. The great thing is that PW is architecturally sound. Thanks Ryan and everyone for refining it while keeping it true to its ideals.

Hi, A bit of background. I am creating a website which lets you navigate through a protein database with 20 million proteins grouped into 50 thousand categories. The database is fixed in size, meaning no need to update/add information in the near future. Queries to the database are pretty standard. The problem I am currently having is the time it takes to create the pages for the proteins (right now around a week). Pages are created reading the data from a csv file. Based on previous posts I found on this forum (link1, link2) I decided to use $database transactions to load the data from a php script (InnoDB engine required). This really boosts performance from 25 pages per second to 200 pages per second. Problem is performance drops as a function of pages created (see attached image). Is this behavior expected? I tried using gc_collect_cycles() but haven't noticed any difference. Is there a way to avoid the degradation in performance? A stable 200 pages per second would be good enough for me. Pseudo code: $handle = fopen($file, "r"); $trans_size = 200 // commit to database every _ pages try { $database->beginTransaction(); for ($i = 0; $row = fgetcsv($handle, 0, " "); ++$i) { // fields from data $title = $row[0]; $size = $row[1]; $len_avg = $row[2]; $len_std = $row[3]; // create page $page = new Page(); $page->template = "protein"; $page->title = $title; $page->size = $size; $page->len_avg = $len_avg; $page->len_std = $len_std; $page->save(); if (($i+1)%$trans_size == 0) { $database->commit(); // $pages->uncacheAll(); // gc_collect_cycles(); $database->beginTransaction(); } } $database->commit(); } I am quiet new to process wire so feel free to criticize me ? Thanks in advance

I think this is the worst solution for probably a small problem