LostKobrakai

I've just found gogs. It's self-hosted like gitlab, but it's written in go and the speed is just impressive. I've it running on the smallest DigitalOcean instance and it's still damn snappy, what I've never had with gitlab.

I also like the getFor() and setFor() functions, which take the pain of namespacing keys away.

In the "Custom PHP Code" snippet there are $page and $pages as local variables, but as the code is evaled in the module itself you can access all other api variables by using the class specific "syntax" like $this->templates or $this->fields.

I'd say with hooks it should be possible.

https://github.com/ryancramerdesign/ProcessWire/issues/1210#issuecomment-107403598

That might be, because not all people are using those services. I've not heard of them until now.

@lpa Please do use the forum's ability to wrap code snippets in code blocks instead of posting it as raw text.

I'm not sure if that's helpful, but json does only allow for either square-bracketed arrays or keyed objects (therefore the "0": {}). Also the api you linked does use [] brackets for features.

Exactly. config.php is just a php files as well. You can do whatever you need there as long as you're at sometime setting the correct properties to the $config variable. But I'd limit it to things really needed at that stage. Anything else should rather go into init or ready.php.

Irrespective of your namespacing issue, you shouldn't edit the index.php as it might be changing on updates. Do rather use the various php files in the site folder (config / init / ready / …) to add any needed functionality.

I've a page which does get the hits of around 25000 users on a single day, peaking at a specific time and my question was mostly in regards of the csrf topic, see here: https://www.fastly.com/blog/caching-uncacheable-csrf-security ESI is one of the options besides using a cookie or even a additional ajax request.

Use PDO::FETCH_NUM and you'll get an multidimensional array of all your selected fields, including the id and the count.

You're still doing all these count()'s. The whole foreach loop isn't necessary if you're also including that COUNT(*) part I wrote above in the mysql query. This will already give you the number of times each option is selected.

There's really not much "fixed" db structure to change anyway. There are about 9 tables, which are installed by default and are not dynamically setup. They handle the data of templates/fields/pages (name, status, hierarchy; not field data) and modules and there's a cache table. These are very unlikely to change in a way to not be backwards compatible. Any other tables are created by fields you're creating in the backend or by some modules. So any changes in the database, which would not be backwards compatible are from fieldtypes or other features, which are explicitly stated as 3.0 only. If you're using those there might be no way back. For example the new repeater field is one of those changes, which didn't need database changes, but still the UI for hiding repeaters is only available in 3.0. So you shouldn't rely on that feature, even though there where no changes to the db, but rather on how the available fields are used. But I'm totally with diogo. I don't see much reason to use 3.0 if you're such concerned. There's essentially no benefit if you're not using new features beyond maybe helping Ryan with reporting issues.

@steveooo This question was already answered in your previous thread by quoting the README of ProcessWire 3, which is written by Ryan. It seems to me you're not really trusting the answers even of our best community members. You won't always get answers directly from Ryan, as he's quite aware and sensible about how much time he's able to invest into reading/writing here and most of it goes into VIP support of his pro modules and the really important topics like bugs or other critical topics.

You've a page field for each of your categories ($field in your code). The snippet of ryan then retrieves the database table of that field and does fetch all the saved id's in that table. Meaning all the pages, which are selected in that field on any page with that field. I'm not sure if you're using these page fields in multiple templates. If so you'd need to extend the query to limit the retrieved pages to only those selected on pages of a specific template. To get the number of uses per option you'd add the following to the query: "SELECT data, COUNT(*) FROM $table GROUP BY data;" This will return a table of id's and their number of occurrences. All in all this would limit your queries to one per page-field (per template; if multiple).

How about such a syntax? I think this would be flexible enough for any kind of tagging structure. // Get me the tags, // which start with "Tech_", // are used in the tags field of "templates=posts, date>today" // and sort them by number of occurences (maybe named count) $pages->find("template=tag, title^=Tech_, in.tags=[templates=posts, date>today], sort=occurences"); // Not limiting to upcoming posts or even posts $pages->find("template=tag, title^=Tech_, in.tags=[*], sort=occurences");

You might take a look at this: https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/

You'd need to loop over the comments manually instead of using the render() method. This is explained in the first post of the topic under "OPTIONAL: Generating your own output". Within that loop you can have as much additional logic as you need.

https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Session/SessionLoginThrottle/SessionLoginThrottle.module#L85-L90

The simplest way would be locking the AmountDiscounted field in the backend and hook to Pages::saveReady and set the value accordingly on each save.

I just copied the parts I used to one piece. You could also use different GET variables, but keep in mind to unset these again after rendering a single pagination. public function pageStart($limit){ $limit = (int) $limit; if(wire('input')->pageNum === 1 || $limit < 1){ return 0; } return (wire('input')->pageNum - 1) * $limit; } $pa = $pages->find("…, limit=15, start=".(!$input->get->second ? pageStart(15) : 0); $pa2 = $pages->find("…, limit=15, start=".($input->get->second ? pageStart(15) : 0); $pagination = $pa->renderPager(); $input->whitelist("second", 1); $pagination2 = $pa2->renderPager();

You can render two independent paginations, but only use one at a time. You'd use the getVars option or $input->whitelist() (if you need some filter values to be populated as well) to add a kinda "switch" GET variable, which tells you which pagination is currently used. When you know which pagination was clicked you can manually set the "start=" part to only the selector of the clicked pagination. There's no automated way to differenciate multiple paginations.

For the redirect maybe read these comments: https://github.com/ryancramerdesign/ProcessWire/issues/1605