LostKobrakai

I think this will become a default in future projects.

So it was my lack of php knowledge . I set it to "" at the beginning of my formvalidation and I thought it would be nicer to read this way, instead of "if($session->data != "")"

Hi there, is this a behavior of "$session->data" a lack of my php knowledge or is this a bug, that empty() returns false? var_dump($session->successmsg); var_dump(!empty("Erfolgreich! Ihnen wurde eine Email mit den Download links zugeschickt.;")); var_dump(!empty($session->successmsg)); $tmp = $session->successmsg; var_dump(!empty($tmp)); Output: string(72) "Erfolgreich! Ihnen wurde eine Email mit den Download links zugeschickt.;" bool(true) bool(false) bool(true) Greetings, Benjamin

As it's presented in the footer of the page, this forum doesn't run in ProcessWire, but on ipboard. I can remember reading a post of Ryan mentioning, that one should use a forum software for forums, which I would also suggest. You could always integrate the forum software in ProcressWire to share things like user logins and accounts.

Hi there, I know I'm digging out a quite old topic, but I just stumbled across this in the processwire blog profile. As the webpages I code right now are often responsive with no real general page layout, exept header and footer part, but lot's of smaller repeated chunks of code (accordions, blocks), I was searching for a simple way of getting templates to work. Plain includes didn't really fit my needs, but a full templating engine seems quite overkill. It's sad that I just now found this class, while I know ProcessWire for over a year now. I think it would be nice to add a paragraph about this in the api section of the page, so it's more visible to new people as a option for generating markup.

Sorry for the bad luck, but in such a situation a backup site would've been the way to go. My personal website is on a really nice german hoster. The only downtime I know of was by a ddos attack on one of the datacenters, where they rent their servers. So even if everything works right on the hosters side you could get downtime just because of such attacks. So there's never a 100% ensureance for uptime of a server.

You want a dynamic cropping, which the default api doesn't offer. You need your own logic for selecting between a free crop to 100px height or a fixed size of 100px height and 200px width.

Just setting the title of the page should work, as processwire converts the title to the name, like it does in the backend. Using rand() isn't a good idea, because you easily could get duplications, where the page just isn't saved and throws an error. If you do something like this you always need to check for duplications and try again a few times, if there is a page with this name already, before saving it.

You're right, as all media is attached to the page it belongs to, you just need to look at this page. In addition do you find all other infos right there, too.

Feel being liked, for all the knowledge about pw I'd like to have

Thanks for your insight in the topic of the different functions before the template loading. But I don't like the uncaching way, because it would also revert every other change made to the $user until this part, which seems not desireable to me. I think I'll go with you second answer, instead of the mysql query I use right now. Edit: Is there any documentation or way to find our more about the order in which modules are loaded in ProcessWire? Especially for module developement this would be useful.

Hey, while my problem with saving a users language is now resolved, I'm now trying to compare the saved language of the user to the language of the current page. With LanguageSupportPageNames activated the "$user->language" is overwritten to reflect the language, which is determined by the url, without a backup of the previous value. Now I could write a module to replace this part of LanguageSupportPageNames, but I don't like to, as I need to update it, if the core changes. Also I could easiely just quickly query the database, which seems also kind of hacky to me, but seems like the way to go for now. What I would prefere is, if the trackChanges() functionality would not only store the changed fieldname, but also it's original value. So a comparison would be as easy as "$user->language == $user->getChanges()->language". Greetings, Benjamin

Yeah, I'll take a look later, but good to know I'm not the only one experiencing this odd behavior. Edit: Thanks, now it's working as expected.

Sure, I didn't intent to criticize your implementation, but it's good to know such things, if one plans to use/configure such a likeing system.

Yeah, I already found that error. I had mistaken your "$thepage->title" and not thought about it more clearly.

You could pass in the data as parameter. function dothing($thepage, $user) { echo $thepage->title; if ($user->isSuperuser()) { // do different } } dothing($page, $user); I thought so, too, but "wire('user')->title" returned me NULL in my test.

An addition to the "Preventing duplicates" topic. In Germany providers are forced by law, to change the IP of their users at least every 24h. In Austria, if I remember correctly it's even once per 8 hours. So while saving the IP is a usable way of preventing to much spam, you should always be aware, that you could also prevent the wrong user to like your stuff.

Repeaters are actually dynamicly created pages with more or less random names. As long as you do not render the name/title of those PageTable pages, there not that much different from handling repeater pages, you could name them however you want. The biggest different would be, that the created pages show up in the pagetree.

It's not directly a workaround, but you could use the current dev version of processwire. There you could replace repeaters with PageTables. They have a quite similar functionality, but use real pages, where the dependencies should work.

Not directly, but you could take a look at the InputfieldTextarea.module. It should load the TinyMCE in the backend.

I think the TinyMCE Module isn't meant to be used in the frontend. At least ProcessWire doesn't generate stuff in your frontend, if you don't explicitly define it to do so and I don't see anything in your template which would call TinyMCE.

What you can see by inspecting the page is, that if you click the link, which just points to the to-be-liked-page. The pagereload is then prevented with jQuery and I think the like is saved via a ajax call. Uniqueness is done via cookies. "likes_likes" & "likes_likes_ready" which exist two times, one for "processwire.com" (sites) and one for "modules.processwire.com". "likes_likes_ready" seems to be a ";" seperated string of just the ids of the liked pages, while "likes_likes" is a ";" seperated string of what seems like "id.timestamp". Guessing from a logic standpoint and the expiration dates, "likes_likes_ready" is written before the ajax call, in case it fails. "likes_likes" is written, if the ajax call responds or I think at the next pagereload, at least not before the like is saved to the database. The timestamp should be there to avoid duplication. As I don't get a undo option if I visit the same module in a different browser it seems like cookies are the only way to limit the option to like a page. That's not the most "secure" way of doing it, because as you can see I could at least like three times with the three browsers on my computer, I could remove the cookies and even some people let the browser automatically trash all cookies with closing the browser. I don't know if Ryan has any backend solution to limit spam liking of modules, but I think there's to less benefit in liking sites and modules, to justify the efforts for the user to do so. That being said to the less technical part. Most people do not really know or care about cookies. Maybe some kill them while resetting their browser history, but for the most part this way should work. If there isn't much benefit from having the likes I don't think much people would care about it being exploitable. But with laws, that say the user needs to confirm, that you're allowed to save cookies, at least they are aware that you save stuff to cookies. That's missing here on processwire.com, but google and many other sites are now asking before saving cookies. So it's up to you if you want a maybe save way of knowing if someone already liked your page or if you need a login (social media or own) to like your pages. Even browser sniffing and advanced stuff aren't more secure than cookies, as modern developer tools can pretend nearly everything.

Thanks for the patience, but even directly setting the id as value doesn't work. As for a fresh install ist a superuser named benni, nothing else changed. Edit: Forgot a answer: It does work, if I change the language in the backend. For the site I want to have this functionallity, it's for a business club, so it's a feature only for logged in members.

What's getting display if you "var_dump($theReply);" just the line before the error? Maybe there's something overriding the variable?