Recently Browsing 0 members
No registered users viewing this page.
By BFD Calendar
I'm still wrestling with the upgrade troubles on OVH.com hosting. I manually upgraded to PW 3.0.98 and Upgrade module 0.0.7. Checking upgrades gives me an "Error loading GitHub branches - https://api.github.com/repos/processwire/processwire/branches - HTTP error(s): 2: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version, 2: fsockopen(): Failed to enable crypto, 2: fsockopen(): unable to connect to ssl://api.github.com:443 (Unknown error) - Check that HTTP requests are not blocked by your server.".
Upgrading or installing other modules doesn't work either. I know it probably has to do with some provider setting on OVH.com, but I've tried several things mentioned in the ProcessWireUpgrade support forum, all to no avail. Server is configured to use PHP 7.0. If anyone here is also on OVH.com and knows a solution I'd be most happy to hear about it.
I stumbled across this on Github ... just breathtaking .... piece of history right there.
A good place to brush up on your Assembly Language
By the way, Margaret Hamilton who worked on the module is considered a programming genius.
Is there a way to change the input options for the images field?
I am trying to figure out if it would make sense to use an external script like Zenphoto as a central media library/manager. How could I connect that with Processwire?
'Choose File' in the images field would have to be able to open that 3rd party media library or a directory on the server or some cloud service instead of (only) the client file manager.
Could justb3a's field type module Image Extra be part of the solution? I will try that and report back. Other field types/modules?
I know there is a pro module Media Manager that does look very slick, but would prefer to make this work with a mature, tested 3rd party script if a central media gallery is never going to be a core Processwire feature.
ProcessWire module to connect a Github OAuth application.
Register a new OAuth application
Fill in module settings
Click the Authorize! link to generate code and access token
There are some predefined endpoints to fetch informations about an user or a repository, get a list of repositories belonging to an organization, fetch content of readme or certain file..
I used it to choose a repository from a list and import the content (e.g. readme, description) to the corresponding fields.
Visit the Github Repository to get a full overview.
Hi, after looking at the 300 open "issues" on Github, it turns out that a lot of them, including some of mine, are labeled "enhancement" / "feature request".
To get the increasing number of issues down there (which might give a wrong impression on how well maintained PW is), and to do sort of a cleanup I was planning to set all of my "issues" which are labeled "enhancement"/"feature request" as closed.
I am assuming that the idea was either good enough and had been recognized for an enhancement consideration and thus stored in a to-do list somewhere else, or the the idea was not good enough and did not survive.
In either case, an "issue" like this,does not need to be open forever, imho. Is closing it the best way to deal with it - or should we leave the step to Ryan (or anyone maintaining this)?
(Also there are many "fixed" / "completed" issues that could be closed eventually.)