wonderer0
Forum Replies Created
-
Forum: Plugins
In reply to: [Participants Database] JS scripts fail because input field ids have changedThanks for your prompt reply.
I have replaced the direct calls to getElementById by calls to my own function that appends the “instance_index”. The buttons are working OK now thanks.
Unfortunately it might be more tricky to fix the #id selectors in the CSS, which is used to control the appearance of the fields displayed by the bootstrap based template. They are specified in a SCSS file that is compiled to CSS by the Gantry 5 framework, so can’t be modified to take into account the instance_index at run-time.
SCSS supports $variables for values (e.g.
color: $dark-1), but when I tried using one in an id selector it failed to compile (e.g.#pdb-some_field$pdb-suffix).There are several possible solutions, in decreasing order of risking name clashes:
- Use the elements’ names as selectors
[name=some_field]. But as the name doesn’t begin with “pdb-” there is a danger of clashing with other elements with the same name. WP pages are quite complex, and I aren’t familiar with all the elements generated. - Give each field an additional pdb class based on its name, then just replace
#pdb-some_fieldselectors with.pdb-some_fieldones. But do you generate anypdb-somethingclasses that could clash with the ones for fields? - Give each element an additional
pdb-name="some_field"attribute, then use[pdb-name=some_field]selectors. This completely avoids the risk of name clashes, but are browsers slower using general attribute selectors than identity or class selectors?
I think it’s got to be one of the last two to avoid the risk of name clashes. If so it would be useful if PDB could automatically add either the class or pdb-name attribute. In the meantime I shall do one of those manually myself, but would like to do it the same way that PDB might be going. What are your thoughts on the matter? You might have a better way of fixing the CSS now that the fields’ ids can change.
P.S.
You might want to move this to a new topic as the subject has changed from JS to CSS.- This reply was modified 5 years, 8 months ago by wonderer0.
Thanks for issuing the update so quickly.
I can confirm the downloads and updates now preserve newlines.Neither dropdown menu allows me to select or enter anything. Clicking anywhere on it just drops down a small dark box that can’t be typed into.
However I have worked around the problem by adding the following lines to the template:
switch ($field_name) { case "first_name": $this->field->link = "../edit-member/?pid=" . $record->get_value('private_id'); break; case "last_name": $this->field->link = "../view-member/?pdb=" . $record->get_value('id'); break; }P.S. I am surprised that nobody else has raised this problem. Perhaps they don’t make their pages private – very dangerous!
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?Ordinary members won’t be using our system at all, so the
pdb_signupform will be used in a way perhaps not intended. Our membership secretary, or another committee member, will use it to add new members’ information, and then use thepdb_recordform to edit or add details later as required. My thinking is that making the two forms as similar as possible means there is less to learn. The group headings are very helpful in making both forms easier to use.Many thanks for all your work on the PDB. It is very useful for a small social club like ours.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?To answer my own question above:
Ticking ‘Show Field Groups’ in ‘Signup Form Settings’ causes the title of each group to be shown, and all the fields displayed using the unmodified
pdb-signup-bootstrap.phptemplate file. Conversely un-ticking ‘Show Groups’ in ‘Record Form Settings’ prevents the titles of the groups from being shown in the[pdb_record]page, but all the fields are still displayed, even when using the normal Bootstrap template.Perhaps the default should be to show the titles for both pages. People will then look round for ways to prevent them if they don’t like them.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?Another problem closely related to
$this->group->printing_title()returning nothing is that on the page none of the Field Groups has a header.Looking at the HTML source for a
[pdb_record]page: each<fieldset>contains a<legend>as it’s first child, followed by a list of<div>s, each containing a<label>+<div>pair.However for the
[pdb_signup]page: each<fieldset>just contains a list of<div>s, each containing a<label>+<div>pair. Presumably it doesn’t have a<legend>because$this->group->printing_title()isn’t true.How do I specify that each Field Group should have a title? Doing so should fix both problems, without having to use a modified template.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?My version of PDB is 1.9.3.1 , which has version 0.4 of the template.
In an earlier post @humpty2 said that he had a similar problem, but it used to be OK. When I replaced version 0.4 of the template with version 0.3 I found in a backup that worked OK.
The main difference between the two seems to be at line 26:
<?php if ( $this->group->has_fields() && $this->group->printing_title() ) : ?>
and a matchingendifat line 56.When I commented out those two lines the fields were displayed OK.
When I inserted at line 25:
<?php echo "[" . $this->group->has_fields() . "|" . $this->group->printing_title() . "]<br>\n"; ?>
it printed out rows of[1|].
The problem seems to be that$this->group->printing_title()is returning false every time, so I have worked around it by deleting that part of the condition.Why does it work OK for you but not for me? Do I need to specify somewhere that titles should be printed? I haven’t knowingly asked for them to be hidden, and can’t see an option like that in Manage Database Fields.
- This reply was modified 7 years, 1 month ago by wonderer0.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?I aren’t very familiar with WAMP or PHP so followed the instructions here. This showed that the current settings in C:\wamp64\bin\php\php7.2.14\php.ini are:
`
error_reporting = E_ALL
display_errors = On
`I also inserted the following into the template pdb-signup-bootstrap.php at line 2, as I wasn’t sure whether or not it needed to be enabled in both places:
`
ini_set(‘display_errors’,1);
error_reporting(E_ALL);
`No errors were displayed, nor was anything written to php_error.log, when the page containing
[pdb_signup template=bootstrap]was loaded.When I tried to force an error by inserting
<?php zzzzzzzz ?>at the end of pdb-signup-bootstrap.php an error message was displayed after the ‘Sign up’ button and messages were written to php_error.log. But when it was<?php $this->zzzzzzzz ?>the page displayed was completely blank and nothing was written to the log.So it looks like only some errors are being reported with the current settings. Could you advise what needs to be set to enable all errors to be reported please, I aren’t clear what you meant by “in your global php settings, not the local one”.
You will see from the above that my PHP version is 7.2.14.
What PHP extension(s) might be required? Presumably ones that are used by the Bootstrap template but not the Default one. Are extension names all of the form
php*.dll. There are no files like that in C:\wamp64.When the normal pdb-signup-bootstrap.php file is used the page source ends with
`
</body>
</html>
`
so it looks like the script is completing OK, but missing all the fields.Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?As I said – nothing is written to the php_error.log when I load the signup page. It hasn’t been written to for several days.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?Thanks for your prompt reply.
Nothing written to php_error.log. Just some GET messages in access.log, mostly for Gantry’s theme.
Is there any way for me to get more debugging info that might help? I am developing the pages in WampServer in Windows 7 on my PC, so everything is local.
Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?All the fields (except Record Info ones) have “Signup” boxes ticked in the Manage Database Fields page. Isn’t this why they are all shown when the Default template is used? How are they treated differently when the Bootstrap template is used? Is there something extra I need to do as well as just adding
template=bootstrapin the shortcode?Forum: Plugins
In reply to: [Participants Database] [pdb_signup] Responsive?I have a similar problem:
[pdb_signup template=bootstrap]gives a page containing only the “Sign Up” button. All the fields are shown when using the default template.This is in a customised Gantry theme with custom CSS that affects the layout of the framework of the page, but I have removed CSS that affected inner contents of the page, including the layout of the [pdb_record template=bootstrap] page which displays OK.
Looking at the page source in Firefox there is no sign of any of the fields, so nothing for the CSS to work on. I tried giving explicit field names, but none appeared.
Forum: Plugins
In reply to: [Participants Database] Participants Database Documentation – blank pagesStrange – all I am still getting for some pages, such as https://xnau.com/work/wordpress-plugins/participants-database/using-the-participants-database-plugin/, is an empty coloured page with no content. I have tried several times over the last 24 hours but it is always empty.
The following all give empty pages:
- Using the Participants Database Plugin
- Quick Setup Guide
- GDPR Information
- Using Participants Database Custom Templates
- Tutorial: A Custom Single Record Template
Also the Developer’s API does give a valid page, but no information about the API, just the heading “Participants Database API”.
Looking at the source of the first it has header lines (<link>, <style>, <script> etc), but no </head> or <body>. It ends with the following three lines:
<!–[if lte IE 9]><link rel=”stylesheet” type=”text/css” href=”https://xnau.com/proto/wp-content/plugins/js_composer/assets/css/vc_lte_ie9.min.css” media=”screen”><![endif]–> <script type=”text/javascript”>
var cli_flush_cache=2;
</script>In Firefox and Chrome the source is 619 lines long, but in Internet Explorer is 653 because of some extra JS defining the function “url”.
I ran the browsers without any extensions that might block the contents, and with Bitlocker’s firewall turned off. I also tried using Ctr+F5 to reload flushing the cache. Can you think of any other ways for me to be able to see those pages?
If not is the documentation available in any other form, such as PDF? If all else fails would you be able to send me those pages as MHT or MAFF files please.
Hi @corylamleorg,
Thanks for getting back.
I have submitted ticket HPZ-2DD-94S7 after the latest version (1.3.5) failed.Strangely that version hadn’t appeared as an update in WP.
Cheers.
- Use the elements’ names as selectors